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 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] From anyrude10 at gmail.com Mon Aug 23 07:41:44 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Mon, 23 Aug 2021 13:11:44 +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 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 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 mark at stackhpc.com Mon Aug 23 07:50:20 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 23 Aug 2021 08:50:20 +0100 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 at 15:08, Dmitry Tantsur wrote: > 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 > In kolla we do not try to own all options - simply create a config override file at /etc/kolla/config/ironic.conf including the above. https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla > 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, < >>>>>>>>> dtantsur at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta < >>>>>>>>>> anyrude10 at gmail.com> 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 wodel.youchi at gmail.com Mon Aug 23 14:11:37 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 23 Aug 2021 15:11:37 +0100 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hi, I redid the undercloud deployment for the Train version for now. And I verified the download URL for the images. My overcloud deployment has moved forward but I still get errors. This is what I got this time : > "TASK [ceph-grafana : wait for grafana to start] > ********************************", > > "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) > 0:12:59.319 ********* ", > > > > > > > * "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": false, > \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > 0.7.151:3100\"}", > > "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": false, > \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > 0.7.155:3100\"}", > > "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": false, > \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > 0.7.165:3100\"}", > > "RUNNING HAND*LER [ceph-prometheus : service handler] > ****************************", > "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) > 0:18:00.087 ********* ", > "PLAY RECAP > *********************************************************************", > > "overcloud-computehci-0 : ok=224 changed=23 unreachable=0 > failed=0 skipped=415 rescued=0 ignored=0 ", > "overcloud-computehci-1 : ok=199 changed=18 unreachable=0 > failed=0 skipped=392 rescued=0 ignored=0 ", > "overcloud-computehci-2 : ok=212 changed=23 unreachable=0 > failed=0 skipped=390 rescued=0 ignored=0 ", > "overcloud-controller-0 : ok=370 changed=52 unreachable=0 > failed=1 skipped=539 rescued=0 ignored=0 ", > "overcloud-controller-1 : ok=308 changed=43 unreachable=0 > failed=1 skipped=495 rescued=0 ignored=0 ", > "overcloud-controller-2 : ok=317 changed=45 unreachable=0 > failed=1 skipped=493 rescued=0 ignored=0 ", > "INSTALLER STATUS > ***************************************************************", > > "Install Ceph Monitor : Complete (0:00:52)", > > "Install Ceph Manager : Complete (0:05:49)", > > "Install Ceph OSD : Complete (0:02:28)", > > "Install Ceph RGW : Complete (0:00:27)", > "Install Ceph Client : Complete (0:00:33)", > "Install Ceph Grafana : In Progress (0:05:54)", > "\tThis phase can be restarted by running: > roles/ceph-grafana/tasks/main.yml", > "Install Ceph Node Exporter : Complete (0:00:28)", > "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) > 0:18:00.094 ********* ", > "=============================================================================== > ", > "ceph-grafana : wait for grafana to start > ------------------------------ 300.77s", > "ceph-facts : get ceph current status > ---------------------------------- 300.27s", > "ceph-container-common : pulling > udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 > image -- 19.04s", > "ceph-mon : waiting for the monitor(s) to form the quorum... > ------------ 12.83s", > "ceph-osd : use ceph-volume lvm batch to create bluestore osds > ---------- 12.13s", > "ceph-osd : wait for all osd to be up > ----------------------------------- 11.88s", > "ceph-osd : set pg_autoscale_mode value on pool(s) > ---------------------- 11.00s", > "ceph-osd : create openstack pool(s) > ------------------------------------ 10.80s", > "ceph-grafana : make sure grafana is down > ------------------------------- 10.66s", > "ceph-osd : customize pool crush_rule > ----------------------------------- 10.15s", > "ceph-osd : customize pool size > ----------------------------------------- 10.15s", > "ceph-osd : customize pool min_size > ------------------------------------- 10.14s", > "ceph-osd : assign application to pool(s) > ------------------------------- 10.13s", > "ceph-osd : list existing pool(s) > ---------------------------------------- 8.59s", "ceph-mon : fetch ceph initial keys > -------------------------------------- 7.01s", > > "ceph-container-common : get ceph version > -------------------------------- 6.75s", > > "ceph-prometheus : start prometheus services > ----------------------------- 6.67s", > > "ceph-mgr : wait for all mgr to be up > ------------------------------------ 6.66s", > > "ceph-grafana : start the grafana-server service > ------------------------- 6.33s", > > "ceph-mgr : create ceph mgr keyring(s) on a mon node > --------------------- 6.26s" > ], > > "failed_when_result": true > > } > 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | > TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ > in case of failure | undercloud | 0:37:30.226345 | 0.25s > > PLAY RECAP > ********************************************************************* > overcloud-computehci-0 : ok=213 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > overcloud-computehci-1 : ok=207 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > overcloud-computehci-2 : ok=207 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > overcloud-controller-0 : ok=237 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > overcloud-controller-1 : ok=232 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > overcloud-controller-2 : ok=232 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > undercloud : ok=100 changed=18 unreachable=0 > failed=1 skipped=37 rescued=0 ignored=0 > > 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Tasks: > 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: > 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.560490 | UUID | > Info | Host | Task Name | Run Time > 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | > SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans > ible | 1082.71s > 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | > SUMMARY | overcloud-controller-1 | Wait for container-puppet t > asks (generate config) to finish | 356.02s > 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | > SUMMARY | overcloud-controller-0 | Wait for container-puppet t > asks (generate config) to finish | 355.74s > 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | > SUMMARY | overcloud-controller-2 | Wait for container-puppet t > asks (generate config) to finish | 355.68s > 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | > SUMMARY | undercloud | Run tripleo-container-image-prepare log > ged to: /var/log/tripleo-container-image-prepare.log | 143.03s > 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | > SUMMARY | overcloud-controller-0 | Wait for puppet host config > uration to finish | 125.36s > 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | > SUMMARY | overcloud-controller-2 | Wait for puppet host config > uration to finish | 125.33s > 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | > SUMMARY | overcloud-controller-1 | Wait for puppet host config > uration to finish | 125.25s > 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | > SUMMARY | overcloud-controller-2 | Run puppet on the host to a > pply IPtables rules | 108.08s > 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | > SUMMARY | overcloud-controller-0 | Run puppet on the host to a > pply IPtables rules | 107.34s > 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | > SUMMARY | overcloud-computehci-2 | Wait for container-puppet t > asks (generate config) to finish | 96.56s > 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | > SUMMARY | overcloud-computehci-0 | Wait for container-puppet t > asks (generate config) to finish | 96.38s > 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | > SUMMARY | overcloud-computehci-1 | Wait for container-puppet t > asks (generate config) to finish | 93.41s > 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | > SUMMARY | overcloud-computehci-0 | Pre-fetch all the container > s | 92.70s > 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | > SUMMARY | overcloud-computehci-2 | Pre-fetch all the container > s | 91.90s > 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | > SUMMARY | overcloud-computehci-1 | Pre-fetch all the container > s | 91.88s > 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | > SUMMARY | overcloud-computehci-1 | Wait for puppet host config > uration to finish | 90.37s > 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | > SUMMARY | overcloud-computehci-2 | Wait for puppet host config > uration to finish | 90.37s > 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | > SUMMARY | overcloud-computehci-0 | Wait for puppet host config > uration to finish | 90.35s > 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did > not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ > 2021-08-23 15:00:24.562379 | The following node(s) had failures: > undercloud > 2021-08-23 15:00:24.562456 | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > *Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts * > Ansible failed, check log at > /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: > http://10.0.2.40:5000 > Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard > Overcloud rc file: /home/stack/overcloudrc > Overcloud Deployed with error > Overcloud configuration failed. > > Could someone help debug this, the ansible.log is huge, I can't see what's the origin of the problem, if someone can point me to the right direction it will aprecciated. Thanks in advance. Regards. Le mer. 18 août 2021 à 18:02, Wesley Hayutin a écrit : > > > 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 sz_cuitao at 163.com Mon Aug 23 14:52:10 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 22:52:10 +0800 Subject: about deploy method In-Reply-To: References: <006d01d7980e$030ff320$092fd960$@163.com> Message-ID: <00a601d7982e$753c90a0$5fb5b1e0$@163.com> instead installs components on demand using virtual environments and optionally LXC. If this is the case, I would rather choose the Docker solution, because I think Docker might be simpler, and a virtualization environment like LXC might be troublesome to configure or manage, because I don't know it. -----Original Message----- From: Radosław Piliszek Sent: Monday, August 23, 2021 9:14 PM To: Tommy Sway Cc: OpenStack Discuss Subject: Re: about deploy method 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 opensrloo at gmail.com Mon Aug 23 14:53:03 2021 From: opensrloo at gmail.com (Ruby Loo) Date: Mon, 23 Aug 2021 10:53:03 -0400 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: Thanks Julia, for your past, present and future dedication to all things metal and taking over the world! We are lucky to have you and maybe ... you'll be back as PTL in some future universe ;) --ruby On Fri, Aug 20, 2021 at 11:05 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 sz_cuitao at 163.com Mon Aug 23 14:53:39 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 22:53:39 +0800 Subject: Is there a new version of FUEL available now? In-Reply-To: <20210823132046.2ejmdu5627puof7u@yuggoth.org> References: <002e01d797e8$c0124a70$4036df50$@163.com> <20210823132046.2ejmdu5627puof7u@yuggoth.org> Message-ID: <00ae01d7982e$a9e00f30$fda02d90$@163.com> Thank you for your reply. It seems that the information I refer to is too old. -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Jeremy Stanley Sent: Monday, August 23, 2021 9:21 PM To: openstack-discuss at lists.openstack.org Subject: Re: Is there a new version of FUEL available now? 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 From sz_cuitao at 163.com Mon Aug 23 14:55:18 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 22:55:18 +0800 Subject: about deploy method In-Reply-To: References: <006d01d7980e$030ff320$092fd960$@163.com> Message-ID: <00b001d7982e$e523b880$af6b2980$@163.com> By the way, I guess Kolla is probably the most popular deployment right now? -----Original Message----- From: Radosław Piliszek Sent: Monday, August 23, 2021 9:14 PM To: Tommy Sway Cc: OpenStack Discuss Subject: Re: about deploy method 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 gaetan.trellu at incloudus.com Mon Aug 23 15:04:28 2021 From: gaetan.trellu at incloudus.com (=?ISO-8859-1?Q?Ga=EBtan_Trellu?=) Date: Mon, 23 Aug 2021 09:04:28 -0600 Subject: [ironic] Not running for PTL this cycle In-Reply-To: Message-ID: <67cbd8e0-b957-450f-b4f1-df8e71117a24@email.android.com> An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Aug 23 15:06:54 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Aug 2021 15:06:54 +0000 Subject: about deploy method In-Reply-To: <00b001d7982e$e523b880$af6b2980$@163.com> References: <006d01d7980e$030ff320$092fd960$@163.com> <00b001d7982e$e523b880$af6b2980$@163.com> Message-ID: <20210823150654.zoctjo4fe4typ6ca@yuggoth.org> On 2021-08-23 22:55:18 +0800 (+0800), Tommy Sway wrote: > By the way, I guess Kolla is probably the most popular deployment > right now? [...] It depends on how you define "most popular" but there is at least some survey data on the subject. See the Deployment Decisions section of https://www.openstack.org/analytics for some ideas. It's hard to say for sure since there's a separate "Ansible" choice which was selected by an overwhelming 46% of respondents, but the "OpenStack-Ansible" and "Puppet" options currently both beat out "Kolla-Ansible" by a few percent. -- 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 gmann at ghanshyammann.com Mon Aug 23 15:07:06 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 23 Aug 2021 10:07:06 -0500 Subject: [nova][placement] PTL nomination open In-Reply-To: <03OZXQ.1NTDOK9MY97N1@est.tech> References: <03OZXQ.1NTDOK9MY97N1@est.tech> Message-ID: <17b738d04a7.1134394c557813.7074841619239278532@ghanshyammann.com> Thanks gibi for all your hard work as PTL and for taking care of responsibilities in a perfect way. -gmann ---- On Tue, 17 Aug 2021 09:54:36 -0500 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 > > > > From sz_cuitao at 163.com Mon Aug 23 15:15:37 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 23:15:37 +0800 Subject: about deploy method In-Reply-To: <20210823150654.zoctjo4fe4typ6ca@yuggoth.org> References: <006d01d7980e$030ff320$092fd960$@163.com> <00b001d7982e$e523b880$af6b2980$@163.com> <20210823150654.zoctjo4fe4typ6ca@yuggoth.org> Message-ID: <00d801d79831$bbdc85d0$33959170$@163.com> I got it, thank you! -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Jeremy Stanley Sent: Monday, August 23, 2021 11:07 PM To: openstack-discuss at lists.openstack.org Subject: Re: about deploy method On 2021-08-23 22:55:18 +0800 (+0800), Tommy Sway wrote: > By the way, I guess Kolla is probably the most popular deployment > right now? [...] It depends on how you define "most popular" but there is at least some survey data on the subject. See the Deployment Decisions section of https://www.openstack.org/analytics for some ideas. It's hard to say for sure since there's a separate "Ansible" choice which was selected by an overwhelming 46% of respondents, but the "OpenStack-Ansible" and "Puppet" options currently both beat out "Kolla-Ansible" by a few percent. -- Jeremy Stanley From rafaelweingartner at gmail.com Mon Aug 23 15:33:08 2021 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Mon, 23 Aug 2021 12:33:08 -0300 Subject: [CLOUDKITTY] Missed CloudKitty meeting today (23 August 2021) Message-ID: Hello guys, I would like to apologize for missing the CloudKitty meeting today. I had an accident with my laptop last thursday, and just now I managed to get my hands on a replacement. If you need something, just let me know. Sorry for the inconvenience; see you guys at our next meeting. -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Aug 23 15:51:01 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 23 Aug 2021 17:51:01 +0200 Subject: [kolla][wallaby] update images stop all vms Message-ID: Hello All, I am new in kolla so probably my procedure is not correct. Last week I installed wallaby and I deployed on my openstack only two virtual machines. Today I tried to updated images so: 1 pulled new images on my local registry 2 pushed new images on my local registry 3 pushed new images from my local registry to controllers and compute nodes (kolla-ansible pull --limit control,compute 4 run kolla-ansible deploy All virtual machines went in shutoff state. What is wrong in my procedure ? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Aug 23 15:58:53 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 23 Aug 2021 10:58:53 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 26th at 1500 UTC Message-ID: <17b73bc6e2d.d8b0455b61221.2930938541566468414@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Aug 26th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Aug 25th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From johfulto at redhat.com Mon Aug 23 16:07:47 2021 From: johfulto at redhat.com (John Fulton) Date: Mon, 23 Aug 2021 12:07:47 -0400 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: On Mon, Aug 23, 2021 at 10:52 AM wodel youchi wrote: > > Hi, > > I redid the undercloud deployment for the Train version for now. And I verified the download URL for the images. > My overcloud deployment has moved forward but I still get errors. > > This is what I got this time : >> >> "TASK [ceph-grafana : wait for grafana to start] ********************************", >> "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) 0:12:59.319 ********* ", >> "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> 0.7.151:3100\"}", >> "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> 0.7.155:3100\"}", >> "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> 0.7.165:3100\"}", I'm not certain of the ceph-ansible version you're using but it should be a version 4 with train. ceph-ansible should already be installed on your undercloud judging by this error and in the latest version 4 this task is where it failed: https://github.com/ceph/ceph-ansible/blob/v4.0.64/roles/ceph-grafana/tasks/configure_grafana.yml#L112-L115 You can check the status of this service on your three controllers and then debug it directly. John >> "RUNNING HANDLER [ceph-prometheus : service handler] ****************************", >> "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) 0:18:00.087 ********* ", >> "PLAY RECAP *********************************************************************", >> "overcloud-computehci-0 : ok=224 changed=23 unreachable=0 failed=0 skipped=415 rescued=0 ignored=0 ", >> "overcloud-computehci-1 : ok=199 changed=18 unreachable=0 failed=0 skipped=392 rescued=0 ignored=0 ", >> "overcloud-computehci-2 : ok=212 changed=23 unreachable=0 failed=0 skipped=390 rescued=0 ignored=0 ", >> "overcloud-controller-0 : ok=370 changed=52 unreachable=0 failed=1 skipped=539 rescued=0 ignored=0 ", >> "overcloud-controller-1 : ok=308 changed=43 unreachable=0 failed=1 skipped=495 rescued=0 ignored=0 ", >> "overcloud-controller-2 : ok=317 changed=45 unreachable=0 failed=1 skipped=493 rescued=0 ignored=0 ", >> >> "INSTALLER STATUS ***************************************************************", >> "Install Ceph Monitor : Complete (0:00:52)", >> "Install Ceph Manager : Complete (0:05:49)", >> "Install Ceph OSD : Complete (0:02:28)", >> "Install Ceph RGW : Complete (0:00:27)", >> "Install Ceph Client : Complete (0:00:33)", >> "Install Ceph Grafana : In Progress (0:05:54)", >> "\tThis phase can be restarted by running: roles/ceph-grafana/tasks/main.yml", >> "Install Ceph Node Exporter : Complete (0:00:28)", >> "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) 0:18:00.094 ********* ", >> "=============================================================================== ", >> "ceph-grafana : wait for grafana to start ------------------------------ 300.77s", >> "ceph-facts : get ceph current status ---------------------------------- 300.27s", >> "ceph-container-common : pulling udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 >> image -- 19.04s", >> "ceph-mon : waiting for the monitor(s) to form the quorum... ------------ 12.83s", >> "ceph-osd : use ceph-volume lvm batch to create bluestore osds ---------- 12.13s", >> "ceph-osd : wait for all osd to be up ----------------------------------- 11.88s", >> "ceph-osd : set pg_autoscale_mode value on pool(s) ---------------------- 11.00s", >> "ceph-osd : create openstack pool(s) ------------------------------------ 10.80s", >> "ceph-grafana : make sure grafana is down ------------------------------- 10.66s", >> "ceph-osd : customize pool crush_rule ----------------------------------- 10.15s", >> "ceph-osd : customize pool size ----------------------------------------- 10.15s", >> "ceph-osd : customize pool min_size ------------------------------------- 10.14s", >> "ceph-osd : assign application to pool(s) ------------------------------- 10.13s", >> "ceph-osd : list existing pool(s) ---------------------------------------- 8.59s", >> >> "ceph-mon : fetch ceph initial keys -------------------------------------- 7.01s", >> "ceph-container-common : get ceph version -------------------------------- 6.75s", >> "ceph-prometheus : start prometheus services ----------------------------- 6.67s", >> "ceph-mgr : wait for all mgr to be up ------------------------------------ 6.66s", >> "ceph-grafana : start the grafana-server service ------------------------- 6.33s", >> "ceph-mgr : create ceph mgr keyring(s) on a mon node --------------------- 6.26s" >> ], >> "failed_when_result": true >> } >> 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ >> in case of failure | undercloud | 0:37:30.226345 | 0.25s >> >> PLAY RECAP ********************************************************************* >> overcloud-computehci-0 : ok=213 changed=117 unreachable=0 failed=0 skipped=120 rescued=0 ignored=0 >> overcloud-computehci-1 : ok=207 changed=117 unreachable=0 failed=0 skipped=120 rescued=0 ignored=0 >> overcloud-computehci-2 : ok=207 changed=117 unreachable=0 failed=0 skipped=120 rescued=0 ignored=0 >> overcloud-controller-0 : ok=237 changed=145 unreachable=0 failed=0 skipped=128 rescued=0 ignored=0 >> overcloud-controller-1 : ok=232 changed=145 unreachable=0 failed=0 skipped=128 rescued=0 ignored=0 >> overcloud-controller-2 : ok=232 changed=145 unreachable=0 failed=0 skipped=128 rescued=0 ignored=0 >> undercloud : ok=100 changed=18 unreachable=0 failed=1 skipped=37 rescued=0 ignored=0 >> >> 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Tasks: 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.560490 | UUID | Info | Host | Task Name | Run Time >> 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans >> ible | 1082.71s >> 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | SUMMARY | overcloud-controller-1 | Wait for container-puppet t >> asks (generate config) to finish | 356.02s >> 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | SUMMARY | overcloud-controller-0 | Wait for container-puppet t >> asks (generate config) to finish | 355.74s >> 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | SUMMARY | overcloud-controller-2 | Wait for container-puppet t >> asks (generate config) to finish | 355.68s >> 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | SUMMARY | undercloud | Run tripleo-container-image-prepare log >> ged to: /var/log/tripleo-container-image-prepare.log | 143.03s >> 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | SUMMARY | overcloud-controller-0 | Wait for puppet host config >> uration to finish | 125.36s >> 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | SUMMARY | overcloud-controller-2 | Wait for puppet host config >> uration to finish | 125.33s >> 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | SUMMARY | overcloud-controller-1 | Wait for puppet host config >> uration to finish | 125.25s >> 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | SUMMARY | overcloud-controller-2 | Run puppet on the host to a >> pply IPtables rules | 108.08s >> 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | SUMMARY | overcloud-controller-0 | Run puppet on the host to a >> pply IPtables rules | 107.34s >> 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | SUMMARY | overcloud-computehci-2 | Wait for container-puppet t >> asks (generate config) to finish | 96.56s >> 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | SUMMARY | overcloud-computehci-0 | Wait for container-puppet t >> asks (generate config) to finish | 96.38s >> 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | SUMMARY | overcloud-computehci-1 | Wait for container-puppet t >> asks (generate config) to finish | 93.41s >> 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | SUMMARY | overcloud-computehci-0 | Pre-fetch all the container >> s | 92.70s >> 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | SUMMARY | overcloud-computehci-2 | Pre-fetch all the container >> s | 91.90s >> 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | SUMMARY | overcloud-computehci-1 | Pre-fetch all the container >> s | 91.88s >> 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | SUMMARY | overcloud-computehci-1 | Wait for puppet host config >> uration to finish | 90.37s >> 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | SUMMARY | overcloud-computehci-2 | Wait for puppet host config >> uration to finish | 90.37s >> 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | SUMMARY | overcloud-computehci-0 | Wait for puppet host config >> uration to finish | 90.35s >> 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >> 2021-08-23 15:00:24.562379 | The following node(s) had failures: undercloud >> 2021-08-23 15:00:24.562456 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts >> Ansible failed, check log at /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: http://10.0.2.40:5000 >> Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard >> Overcloud rc file: /home/stack/overcloudrc >> Overcloud Deployed with error >> Overcloud configuration failed. >> > > > Could someone help debug this, the ansible.log is huge, I can't see what's the origin of the problem, if someone can point me to the right direction it will aprecciated. > Thanks in advance. > > Regards. > > Le mer. 18 août 2021 à 18:02, Wesley Hayutin a écrit : >> >> >> >> 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 From jungleboyj at gmail.com Mon Aug 23 16:14:09 2021 From: jungleboyj at gmail.com (Jay Bryant) Date: Mon, 23 Aug 2021 11:14:09 -0500 Subject: [election][tc]Jay Bryant candidacy for Technical Committee ... Message-ID: Hello OpenStack Community! I would like to announce my candidacy for another term on the Technical Committee. First of all, I have appreciated the opportunity to serve on the TC for the last two years.  I have endeavored to use this time to get to know the broader community better and have also tried to better understand the role and activities of the TC. With this experience under my belt I would like to continue to work with the TC in the coming year to address some of the challenges that currently face the community.  Most importantly the challenge of getting more new companies and contributors to engage with the OpenStack community.  I also would like to continue to work with the TC to innovate and improve OpenStack's processes given the always changing landscape of the community. I appreciate you all taking the time to read/consider my candidacy! Sincerely, Jay Bryant (jungleboyj) From jungleboyj at gmail.com Mon Aug 23 16:15:23 2021 From: jungleboyj at gmail.com (Jay Bryant) Date: Mon, 23 Aug 2021 11:15:23 -0500 Subject: [election][tc]Jay Bryant candidacy for Technical Committee ... Message-ID: Hello OpenStack Community! I would like to announce my candidacy for another term on the Technical Committee. First of all, I have appreciated the opportunity to serve on the TC for the last two years.  I have endeavored to use this time to get to know the broader community better and have also tried to better understand the role and activities of the TC. With this experience under my belt I would like to continue to work with the TC in the coming year to address some of the challenges that currently face the community.  Most importantly the challenge of getting more new companies and contributors to engage with the OpenStack community.  I also would like to continue to work with the TC to innovate and improve OpenStack's processes given the always changing landscape of the community. I appreciate you all taking the time to read/consider my candidacy! Sincerely, Jay Bryant (jungleboyj) From fpantano at redhat.com Mon Aug 23 16:28:12 2021 From: fpantano at redhat.com (Francesco Pantano) Date: Mon, 23 Aug 2021 18:28:12 +0200 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hello, thanks John for your reply here. A few more comments inline: On Mon, Aug 23, 2021 at 6:16 PM John Fulton wrote: > On Mon, Aug 23, 2021 at 10:52 AM wodel youchi > wrote: > > > > Hi, > > > > I redid the undercloud deployment for the Train version for now. And I > verified the download URL for the images. > > My overcloud deployment has moved forward but I still get errors. > > > > This is what I got this time : > >> > >> "TASK [ceph-grafana : wait for grafana to start] > ********************************", > >> "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) > 0:12:59.319 ********* ", > >> "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": > false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > >> 0.7.151:3100\"}", > >> "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": > false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > >> 0.7.155:3100\"}", > >> "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": > false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 > >> 0.7.165:3100\"}", > > I'm not certain of the ceph-ansible version you're using but it should > be a version 4 with train. ceph-ansible should already be installed on > your undercloud judging by this error and in the latest version 4 this > task is where it failed: > > > https://github.com/ceph/ceph-ansible/blob/v4.0.64/roles/ceph-grafana/tasks/configure_grafana.yml#L112-L115 > > You can check the status of this service on your three controllers and > then debug it directly. As John pointed out, ceph-ansible is able to configure, render and start the associated systemd unit for all the ceph monitoring stack components (node-exported, prometheus, alertmanager and grafana). You can ssh to your controllers, and check the systemd unit associated, checking the journal to see why they failed to start (I saw there's a timeout waiting for the container to start). A potential plan, in this case, could be: 1. check the systemd unit (I guess you can start with grafana which is the failed service) 2. look at the journal logs (feel free to attach here the relevant part of the output) 3. double check the network where the service is bound (can you attach the /var/lib/mistral//ceph-ansible/group_vars/all.yaml) * The grafana process should be run on the storage network, but I see a "Timeout when waiting for 10.200.7.165:3100": is that network the right one? > > John > > >> "RUNNING HANDLER [ceph-prometheus : service handler] > ****************************", > >> "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) > 0:18:00.087 ********* ", > >> "PLAY RECAP > *********************************************************************", > >> "overcloud-computehci-0 : ok=224 changed=23 > unreachable=0 failed=0 skipped=415 rescued=0 ignored=0 ", > >> "overcloud-computehci-1 : ok=199 changed=18 > unreachable=0 failed=0 skipped=392 rescued=0 ignored=0 ", > >> "overcloud-computehci-2 : ok=212 changed=23 > unreachable=0 failed=0 skipped=390 rescued=0 ignored=0 ", > >> "overcloud-controller-0 : ok=370 changed=52 > unreachable=0 failed=1 skipped=539 rescued=0 ignored=0 ", > >> "overcloud-controller-1 : ok=308 changed=43 > unreachable=0 failed=1 skipped=495 rescued=0 ignored=0 ", > >> "overcloud-controller-2 : ok=317 changed=45 > unreachable=0 failed=1 skipped=493 rescued=0 ignored=0 ", > >> > >> "INSTALLER STATUS > ***************************************************************", > >> "Install Ceph Monitor : Complete (0:00:52)", > >> "Install Ceph Manager : Complete (0:05:49)", > >> "Install Ceph OSD : Complete (0:02:28)", > >> "Install Ceph RGW : Complete (0:00:27)", > >> "Install Ceph Client : Complete (0:00:33)", > >> "Install Ceph Grafana : In Progress (0:05:54)", > >> "\tThis phase can be restarted by running: > roles/ceph-grafana/tasks/main.yml", > >> "Install Ceph Node Exporter : Complete (0:00:28)", > >> "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) > 0:18:00.094 ********* ", > >> > "=============================================================================== > ", > >> "ceph-grafana : wait for grafana to start > ------------------------------ 300.77s", > >> "ceph-facts : get ceph current status > ---------------------------------- 300.27s", > >> "ceph-container-common : pulling > udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 > >> image -- 19.04s", > >> "ceph-mon : waiting for the monitor(s) to form the quorum... > ------------ 12.83s", > >> "ceph-osd : use ceph-volume lvm batch to create bluestore osds > ---------- 12.13s", > >> "ceph-osd : wait for all osd to be up > ----------------------------------- 11.88s", > >> "ceph-osd : set pg_autoscale_mode value on pool(s) > ---------------------- 11.00s", > >> "ceph-osd : create openstack pool(s) > ------------------------------------ 10.80s", > >> "ceph-grafana : make sure grafana is down > ------------------------------- 10.66s", > >> "ceph-osd : customize pool crush_rule > ----------------------------------- 10.15s", > >> "ceph-osd : customize pool size > ----------------------------------------- 10.15s", > >> "ceph-osd : customize pool min_size > ------------------------------------- 10.14s", > >> "ceph-osd : assign application to pool(s) > ------------------------------- 10.13s", > >> "ceph-osd : list existing pool(s) > ---------------------------------------- 8.59s", > >> > >> "ceph-mon : fetch ceph initial keys > -------------------------------------- 7.01s", > >> "ceph-container-common : get ceph version > -------------------------------- 6.75s", > >> "ceph-prometheus : start prometheus services > ----------------------------- 6.67s", > >> "ceph-mgr : wait for all mgr to be up > ------------------------------------ 6.66s", > >> "ceph-grafana : start the grafana-server service > ------------------------- 6.33s", > >> "ceph-mgr : create ceph mgr keyring(s) on a mon node > --------------------- 6.26s" > >> ], > >> "failed_when_result": true > >> } > >> 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | > TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ > >> in case of failure | undercloud | 0:37:30.226345 | 0.25s > >> > >> PLAY RECAP > ********************************************************************* > >> overcloud-computehci-0 : ok=213 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > >> overcloud-computehci-1 : ok=207 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > >> overcloud-computehci-2 : ok=207 changed=117 unreachable=0 > failed=0 skipped=120 rescued=0 ignored=0 > >> overcloud-controller-0 : ok=237 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > >> overcloud-controller-1 : ok=232 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > >> overcloud-controller-2 : ok=232 changed=145 unreachable=0 > failed=0 skipped=128 rescued=0 ignored=0 > >> undercloud : ok=100 changed=18 unreachable=0 > failed=1 skipped=37 rescued=0 ignored=0 > >> > >> 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total > Tasks: 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed > Time: 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.560490 | UUID | > Info | Host | Task Name | Run Time > >> 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | > SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans > >> ible | 1082.71s > >> 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | > SUMMARY | overcloud-controller-1 | Wait for container-puppet t > >> asks (generate config) to finish | 356.02s > >> 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | > SUMMARY | overcloud-controller-0 | Wait for container-puppet t > >> asks (generate config) to finish | 355.74s > >> 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | > SUMMARY | overcloud-controller-2 | Wait for container-puppet t > >> asks (generate config) to finish | 355.68s > >> 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | > SUMMARY | undercloud | Run tripleo-container-image-prepare log > >> ged to: /var/log/tripleo-container-image-prepare.log | 143.03s > >> 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | > SUMMARY | overcloud-controller-0 | Wait for puppet host config > >> uration to finish | 125.36s > >> 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | > SUMMARY | overcloud-controller-2 | Wait for puppet host config > >> uration to finish | 125.33s > >> 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | > SUMMARY | overcloud-controller-1 | Wait for puppet host config > >> uration to finish | 125.25s > >> 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | > SUMMARY | overcloud-controller-2 | Run puppet on the host to a > >> pply IPtables rules | 108.08s > >> 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | > SUMMARY | overcloud-controller-0 | Run puppet on the host to a > >> pply IPtables rules | 107.34s > >> 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | > SUMMARY | overcloud-computehci-2 | Wait for container-puppet t > >> asks (generate config) to finish | 96.56s > >> 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | > SUMMARY | overcloud-computehci-0 | Wait for container-puppet t > >> asks (generate config) to finish | 96.38s > >> 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | > SUMMARY | overcloud-computehci-1 | Wait for container-puppet t > >> asks (generate config) to finish | 93.41s > >> 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | > SUMMARY | overcloud-computehci-0 | Pre-fetch all the container > >> s | 92.70s > >> 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | > SUMMARY | overcloud-computehci-2 | Pre-fetch all the container > >> s | 91.90s > >> 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | > SUMMARY | overcloud-computehci-1 | Pre-fetch all the container > >> s | 91.88s > >> 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | > SUMMARY | overcloud-computehci-1 | Wait for puppet host config > >> uration to finish | 90.37s > >> 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | > SUMMARY | overcloud-computehci-2 | Wait for puppet host config > >> uration to finish | 90.37s > >> 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | > SUMMARY | overcloud-computehci-0 | Wait for puppet host config > >> uration to finish | 90.35s > >> 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End > Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes which > did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ > >> 2021-08-23 15:00:24.562379 | The following node(s) had failures: > undercloud > >> 2021-08-23 15:00:24.562456 | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts > >> Ansible failed, check log at > /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: > http://10.0.2.40:5000 > >> Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard > >> Overcloud rc file: /home/stack/overcloudrc > >> Overcloud Deployed with error > >> Overcloud configuration failed. > >> > > > > > > Could someone help debug this, the ansible.log is huge, I can't see > what's the origin of the problem, if someone can point me to the right > direction it will aprecciated. > > Thanks in advance. > > > > Regards. > > > > Le mer. 18 août 2021 à 18:02, Wesley Hayutin a > écrit : > >> > >> > >> > >> 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 > > > -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: From gthiemonge at redhat.com Mon Aug 23 16:35:51 2021 From: gthiemonge at redhat.com (Gregory Thiemonge) Date: Mon, 23 Aug 2021 18:35:51 +0200 Subject: [election][Octavia] PTL candidacy for Yoga Message-ID: Hi everyone, I would like to nominate myself for Octavia PTL for the Yoga release. I am the current PTL for the Xena release and I would like to continue to serve our team for the next release. I have been an Octavia contributor for more than 2 years, and a core reviewer for 3 releases. My focus will be to continue the tasks that we have worked on during Xena: completing the Amphorav2 driver feature, supporting multiple subnets on a Load Balancer VIP, improving our CI coverage, ... Thanks for your consideration, Gregory -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Mon Aug 23 17:06:50 2021 From: amy at demarco.com (Amy Marrich) Date: Mon, 23 Aug 2021 12:06:50 -0500 Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations ending in less than 24 hours Message-ID: A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Aug 24, 2021 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2021-08-17 23:45:00 UTC Nominations end @ 2021-08-24 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 1 day, 7:37:12 Nominations progress : 81.18% --------------------------------------------------- Projects[1] : 47 Projects with candidates : 28 ( 52.00%) Projects with election : 1 ( 2.00%) --------------------------------------------------- Need election : 1 (Cyborg) Need appointment : 19 (Adjutant Cinder Cloudkitty Designate Heat Ironic Magnum Manila Monasca OpenStack_Charms Openstack_Chef Puppet_OpenStack Release_Management Requirements Sahara Storlets Swift Tripleo Zun) =================================================== Stats gathered @ 2021-08-23 16:07:48 UTC This means that with approximately 2 days left, 23 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. There are also currently 4 confirmed candidates for the 4 open Technical Committee. Thank you, Amy (spotz) On behalf of all the Election Officials [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsanjeewa at kln.ac.lk Mon Aug 23 17:49:19 2021 From: bsanjeewa at kln.ac.lk (Buddhika Godakuru) Date: Mon, 23 Aug 2021 23:19:19 +0530 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Dear Anirudh, I do remember I also had some odd behaviour with HPE ProLiant DL380 Gen10 server when using UEFI boot. I was using bifrost to deploy the server with Kayobe (before deploying the cloud services). I could overcome the issue by adding capability "boot_mode:uefi" to the node. So my complete capability string was "cpu_vt:true,cpu_aes:true,cpu_hugepages:true,cpu_hugepages_1g:true,cpu_txt:true,boot_option:local,boot_mode:uefi" Using guide Ironic Advanced Features Guide [1]. Hope this helps [1] https://docs.openstack.org/ironic/wallaby/install/advanced.html On Mon, 23 Aug 2021 at 20:24, 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 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] >>> >> -- බුද්ධික සංජීව ගොඩාකුරු Buddhika Sanjeewa Godakuru Systems Analyst/Programmer Deputy Webmaster / University of Kelaniya Information and Communication Technology Centre (ICTC) University of Kelaniya, Sri Lanka, Kelaniya, Sri Lanka. Mobile : (+94) 071 5696981 Office : (+94) 011 2903420 / 2903424 -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  University of Kelaniya Sri Lanka, accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. If you are not the intended recipient, this email and/or any information it contains should not be copied, disclosed, retained or used by you or any other party and the email and all its contents should be promptly deleted fully from our system and the sender informed. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavofaganello.santos at windriver.com Mon Aug 23 19:00:03 2021 From: gustavofaganello.santos at windriver.com (Gustavo Faganello Santos) Date: Mon, 23 Aug 2021 16:00:03 -0300 Subject: [horizon][dev] Auto-Refresh Feature Proposal In-Reply-To: References: Message-ID: Hello, Michael! Thanks for your reply. It's nice to see that some work has already been done for auto-refresh in AngularJS pages. That could come in handy for tackling the issue I described previously. With that in mind, would you know if the Horizon cores would be open to us submitting our auto-refresh for Django pages upstream? If so, should the feature be a bit more thoroughly discussed via e-mail before a spec is submitted for review in Gerrit? Looking to follow these steps: https://docs.openstack.org/charm-guide/latest/feature-specification.html Please let me know if those are not the best steps to follow at this first moment. Thank you! Gustavo F. Santos On 18/08/2021 20:44, Michael Johnson wrote: > 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 johnsomor at gmail.com Mon Aug 23 19:55:28 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 23 Aug 2021 12:55:28 -0700 Subject: [horizon][dev] Auto-Refresh Feature Proposal In-Reply-To: References: Message-ID: Hi Gustavo, I am sorry, but I can't speak for the horizon team (I primarily work on Octavia and Designate). That said, in the OpenStack community contributions are always welcome. I know there has been a discussion about working on a new dashboard project called skyline[1], so I would recommend having a discussion with the horizon team before investing a lot of time on the current code base. That said, I would expect a blueprint and/or specification would mostly apply to both projects. The link you provided is for a deployment project "OpenStack Charms" and is likely not the process that the horizon team uses. Horizon has a developer guide here: https://docs.openstack.org/horizon/latest/contributor/index.html This includes a section on creating a new feature for horizon. I would recommend creating the blueprint and even the specification to get the discussion started if you are not getting a timely response on the email list. Michael [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024088.html On Mon, Aug 23, 2021 at 12:00 PM Gustavo Faganello Santos wrote: > > > Hello, Michael! > > Thanks for your reply. > > It's nice to see that some work has already been done for auto-refresh > in AngularJS pages. That could come in handy for tackling the issue I > described previously. > > With that in mind, would you know if the Horizon cores would be open to > us submitting our auto-refresh for Django pages upstream? > > If so, should the feature be a bit more thoroughly discussed via e-mail > before a spec is submitted for review in Gerrit? Looking to follow these > steps: > https://docs.openstack.org/charm-guide/latest/feature-specification.html > > Please let me know if those are not the best steps to follow at this > first moment. > > Thank you! > Gustavo F. Santos > > On 18/08/2021 20:44, Michael Johnson wrote: > > 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 johnsomor at gmail.com Mon Aug 23 20:15:23 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 23 Aug 2021 13:15:23 -0700 Subject: [election][Designate] PTL candidacy for Yoga Message-ID: Hello OpenStack community, I would like to announce my candidacy for PTL of Designate for the Yoga cycle. I would like to continue to support the Designate team for the Yoga release. We have made good progress improving the Designate tempest tests and documentation, but we have more work to do. I am also excited to see progresson new features. Thank you for your support and your consideration for Yoga, Michael Johnson (johnsom) From mdemaced at redhat.com Mon Aug 23 20:39:00 2021 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Mon, 23 Aug 2021 22:39:00 +0200 Subject: [election][kuryr] PTL Candidacy for Yoga Message-ID: Hello OpenStack community, I would like to continue serving as Kuryr PTL for the Yoga cycle. I have started serving as Kuryr PTL in the Wallaby cycle. It has been a great opportunity to contribute back to the community as PTL and I would like to continue doing that. In the Xena cycle we achieved the following goals: * CI improvements: started moving gates to use OVN by default while still having a few supporting OVS. * Dev env improvements: Support for Kubeadm for DevStack installations. * Extended features in Kuryr: Support to reconcile Load Balancer with respective Kubernetes Service, improvement on the Kuryr logs. * Increased diversity of contributors with great addition of contributors from the Outreachy program. For the next cycle, I propose the following goals for Kuryr: * Improve CI: we already did great improvements, but we must continuously work on it to provide better and quicker feedback during the development process. * Migrate CNI code from pyroute2.IPDB to NDB; Add support to reconciliation of other Kubernetes resources; Reduce OpenStack resource usage; Provide better debugging by relying on Kubernetes events. Thank you for your consideration. Kind regards, Maysa Macedo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Mon Aug 23 21:23:30 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 23 Aug 2021 17:23:30 -0400 Subject: [horizon][dev] Auto-Refresh Feature Proposal In-Reply-To: References: Message-ID: On Wed, Aug 18, 2021 at 4:44 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. I think you should totally push up the patch on Gerrit and I hope that the Horizon team looks into it, I personally think it's a great idea from an operators perspective. > > > Kind regards. > > Gustavo Santos -- Mohammed Naser VEXXHOST, Inc. From gagehugo at gmail.com Mon Aug 23 21:34:29 2021 From: gagehugo at gmail.com (Gage Hugo) Date: Mon, 23 Aug 2021 16:34:29 -0500 Subject: No meeting tomorrow Message-ID: Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be Aug 31st. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Mon Aug 23 21:50:08 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Mon, 23 Aug 2021 23:50:08 +0200 Subject: [election][ironic] PTL Candidacy for Yoga Message-ID: Hello Stackers, I would like to nominate myself to serve as Ironic PTL for the Yoga cycle. I've been working with OpenStack since 2015 and contributing to ironic since Oct 2018 (Stein release). I hope that we as a community can continue to achieve goals together, let's not forget that our main objective is to take over the world and make operator's life easier! We should also aim to grow our contributor base and continue to spread the word about Ironic (blog posts, social media, etc). Features that I think we should aim for during the next cycle: Virtual Media visibility, Security Interface using Keylime. Best regards, -- *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 Mon Aug 23 22:38:44 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Mon, 23 Aug 2021 18:38:44 -0400 Subject: [election][ironic] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: Thanks Iury for stepping up On Mon, Aug 23, 2021 at 5:51 PM Iury Gregory wrote: > Hello Stackers, > > I would like to nominate myself to serve as Ironic PTL for the Yoga cycle. > I've been working with OpenStack since 2015 and contributing to ironic > since Oct 2018 (Stein release). > > I hope that we as a community can continue to achieve goals together, > let's not forget that our main objective is to take over the world and make > operator's life easier! > We should also aim to grow our contributor base and continue to spread the > word about Ironic (blog posts, social media, etc). > Features that I think we should aim for during the next cycle: Virtual > Media visibility, Security Interface using Keylime. > > Best regards, > -- > > > *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 manchandavishal143 at gmail.com Tue Aug 24 02:54:36 2021 From: manchandavishal143 at gmail.com (vishal manchanda) Date: Tue, 24 Aug 2021 08:24:36 +0530 Subject: [horizon][dev] Auto-Refresh Feature Proposal In-Reply-To: References: Message-ID: Hi Gustavo, It would be nice to have an auto-refresh feature in horizon. Horizon team will be happy to review your patches. If I remember correctly, a patch for the same feature is pushed in the past but not merged due to some issues or no response from the author. You can refer to horizon documentation about how to add a new feature in horizon [1]. Feel free to reach me or other horizon team members in case of any queries on IRC (#openstack-horizon) at OFTC n/w. Thanks & Regards, Vishal Manchanda [1] https://docs.openstack.org/horizon/latest/contributor/contributing.html#new-feature-planning On Tue, Aug 24, 2021 at 2:54 AM Mohammed Naser wrote: > On Wed, Aug 18, 2021 at 4:44 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. > > I think you should totally push up the patch on Gerrit and I hope that > the Horizon team looks into it, I personally think it's a great idea > from an operators perspective. > > > > > > > Kind regards. > > > > Gustavo Santos > > > > -- > Mohammed Naser > VEXXHOST, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Tue Aug 24 04:00:52 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 24 Aug 2021 06:00:52 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan Message-ID: Hello Team, I was able to deploy Openstack with Magnum and Zun enabled. Unfortunately, When I create a cluster, Heat configure the fix/_network for the nodes with Vlan and the nodes fail to get IPs. I was wondering if it is possible to trick the heat templates to create vxlan network instead of vlan. Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Tue Aug 24 05:11:05 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Tue, 24 Aug 2021 14:11:05 +0900 Subject: [election][storlets] PTL Candidacy for Yoga Message-ID: Hi All, I'd like to announce my candidacy to continue the PTL role for Storlets project in the Yoga cycle. After inactive recent cycles, we fortunately got some interest around the project again. So I'll propose the items below as our focus during the next cycle. - Keep compatibility with Swift. This is always top-priority - Merge some patches still open to achieve easier operation and improve resource efficiency Thank you for your consideration. Thank you, Takashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Tue Aug 24 06:34:14 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Mon, 23 Aug 2021 23:34:14 -0700 Subject: [election][manila][ptl] PTL Candidacy for Yoga Message-ID: Hello fellow zorillas and other interested stackers, I'm expressing interest to continue serving as PTL for the OpenStack Manila team through the Yoga cycle. I've used my great privilege in this role to affect the community in many small and significant ways over the past four cycles. It has been a smooth ride because of stellar contributors who're beyond motivated and enthusiastic to develop and maintain impactful software while having fun. The enthusiasm is bolstered by grit to be a team with a difference. We jump at the opportunity to help a user or mentor and welcome new contributors or back each other up and help get stuff done, regardless of the "barriers" of affiliation. I enjoy being the occasional enabler to this camaraderie. During the Xena cycle, we mentored two Outreachy interns and on-boarded several new contributors. We added sub team core maintainers in the manila-tempest-plugin project and a new core maintainer across the manila repos. We drove down bug backlogs through bug squash weeks, swarmed to work on the OpenStackClient with a hack-a-thon and crushed the goal to drive down tech debt. We kept the momentum on several multi-cycle efforts such as OpenStackSDK integration, Secure RBAC, Active/Active HA. The Yoga cycle will be critical in our efforts to drive some of these multi-cycle efforts to closure. So, if you will have me, I wish to serve you through the Yoga cycle and get things done. I would tell you it's going to be the best release ever; but I would hold out the distinction for the Zorilla cycle - yes that's what we'll name it, what other cool name will we have anyway :) Thank you for your support, Goutham Pacha Ravi IRC: gouthamr -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Tue Aug 24 06:55:29 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 24 Aug 2021 08:55:29 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello MOhamed, I think the Kubernetes cluster is ok but it when I deploy it, It creates a fixed network using vlan which I am not using for internal networks. When I create a a vxlan Network and use it in the cluster creation, It fails. Is there a trick around this ? Regards Tony Karera On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: > 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 ignaziocassano at gmail.com Tue Aug 24 07:02:07 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 24 Aug 2021 09:02:07 +0200 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: References: Message-ID: Hello, about the above issue, we discussed on yesterday on openstack-kolla IRC. The issue is not related to masakary, but it happens when nova-compute is redeployed with the following error in linvirt.log: 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, package: 0ubuntu8.12 (Christian Ehrhardt Tue, 20 Jul 2021 14:13:56 +0200) 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 2021-08-24 06:59:25.012+0000: 3224764: error : dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary /usr/sbin/dnsmasq: No such file or directory 2021-08-24 06:59:25.857+0000: 3224822: error : qemuMonitorOpenUnix:292 : failed to connect to monitor socket: Connection refused 2021-08-24 06:59:25.876+0000: 3224821: error : qemuMonitorOpenUnix:292 : failed to connect to monitor socket: Connection refused 2021-08-24 06:59:44.670+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-alpha' on this host 2021-08-24 06:59:44.673+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-arm' on this host 2021-08-24 06:59:44.674+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-arm' on this host 2021-08-24 06:59:44.677+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-arm' on this host 2021-08-24 06:59:44.681+0000: 3224749: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-aarch64' on this host 2021-08-24 06:59:44.684+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-cris' on this host 2021-08-24 06:59:44.713+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-lm32' on this host 2021-08-24 06:59:44.716+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-m68k' on this host 2021-08-24 06:59:44.719+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-microblaze' on this host 2021-08-24 06:59:44.721+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-microblazeel' on this host 2021-08-24 06:59:44.725+0000: 3224749: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-mips' on this host 2021-08-24 06:59:44.727+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-mipsel' on this host 2021-08-24 06:59:44.731+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-mips64' on this host 2021-08-24 06:59:44.733+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-mips64el' on this host 2021-08-24 06:59:44.736+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc' on this host 2021-08-24 06:59:44.739+0000: 3224749: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64' on this host 2021-08-24 06:59:44.741+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64' on this host 2021-08-24 06:59:44.744+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64' on this host 2021-08-24 06:59:44.747+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64le' on this host 2021-08-24 06:59:44.750+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64le' on this host 2021-08-24 06:59:44.753+0000: 3224749: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-ppc64le' on this host 2021-08-24 06:59:44.755+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-riscv32' on this host 2021-08-24 06:59:44.758+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-riscv64' on this host 2021-08-24 06:59:44.761+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-s390x' on this host 2021-08-24 06:59:44.763+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-sh4' on this host 2021-08-24 06:59:44.766+0000: 3224749: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-sh4eb' on this host 2021-08-24 06:59:44.768+0000: 3224751: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-sparc' on this host 2021-08-24 06:59:44.771+0000: 3224753: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-sparc64' on this host 2021-08-24 06:59:44.773+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-unicore32' on this host 2021-08-24 06:59:44.795+0000: 3224750: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-xtensa' on this host 2021-08-24 06:59:44.798+0000: 3224752: error : virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported by '/usr/bin/qemu-system-xtensaeb' on this host Ignazio Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello All, > I am new in kolla so probably my procedure is not correct. > Last week I installed wallaby and I deployed on my openstack only two > virtual machines. > Today I tried to updated images so: > > 1 pulled new images on my local registry > 2 pushed new images on my local registry > 3 pushed new images from my local registry to controllers and compute nodes > (kolla-ansible pull --limit control,compute > 4 run kolla-ansible deploy > > All virtual machines went in shutoff state. > What is wrong in my procedure ? > > Regards > Ignazio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Tue Aug 24 07:26:22 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Tue, 24 Aug 2021 12:26:22 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hi Tony, You can try by creating your private vxlan network prior to deployment of cluster and explicitly create your cluster in vxlan network. --fixed-network private --fixed-subnet private-subnet You can specify above while creating a cluster. Ammad On Tue, Aug 24, 2021 at 11:59 AM Karera Tony wrote: > Hello MOhamed, > > I think the Kubernetes cluster is ok but it when I deploy it, It creates a > fixed network using vlan which I am not using for internal networks. > > When I create a a vxlan Network and use it in the cluster creation, It > fails. Is there a trick around this ? > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: > >> 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. >> ------------------------------------------------------------------------------ >> >> -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Tue Aug 24 08:08:49 2021 From: eblock at nde.ag (Eugen Block) Date: Tue, 24 Aug 2021 08:08:49 +0000 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: Message-ID: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> Of course you need a running nova-conductor, how did you launch VMs before? Zitat von KK CHN : > 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. >> From mark at stackhpc.com Tue Aug 24 08:35:54 2021 From: mark at stackhpc.com (Mark Goddard) Date: Tue, 24 Aug 2021 09:35:54 +0100 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: Julia, you join the long list of legendary Ironic PTLs. Enjoy the reduced stress as you hang up your hat. Mark On Fri, 20 Aug 2021 at 16:06, 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 tonykarera at gmail.com Tue Aug 24 10:41:21 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 24 Aug 2021 12:41:21 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Ammad, I had done as explained and it worked upto a certain point. The master node was created but the cluster remained in Creation in progress for over an hour and failed with error below Stack Faults as follows: default-master Timed out default-worker Timed out Regards Tony Karera On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: > Hi Tony, > > You can try by creating your private vxlan network prior to deployment of > cluster and explicitly create your cluster in vxlan network. > > --fixed-network private --fixed-subnet private-subnet > > You can specify above while creating a cluster. > > Ammad > > On Tue, Aug 24, 2021 at 11:59 AM Karera Tony wrote: > >> Hello MOhamed, >> >> I think the Kubernetes cluster is ok but it when I deploy it, It creates >> a fixed network using vlan which I am not using for internal networks. >> >> When I create a a vxlan Network and use it in the cluster creation, It >> fails. Is there a trick around this ? >> Regards >> >> Tony Karera >> >> >> >> >> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >> >>> 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. >>> ------------------------------------------------------------------------------ >>> >>> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Tue Aug 24 10:42:31 2021 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Tue, 24 Aug 2021 07:42:31 -0300 Subject: [election][cloudkitty] PTL Candidacy for Yoga Message-ID: Hello Cloudkitters, I would like to nominate myself to serve as Cloudkitty PTL for the Yoga cycle. I've been working with OpenStack since 2018 and contributing to Cloudkitty since May 2019. I hope that we can continue to achieve goals together, making CloudKitty better and more robust. We should also aim to grow our contributor base and continue to spread the word about CloudKitty (blog posts, social media, etc). Features that I think we should aim for during the next cycle: the reprocessing API (https://review.opendev.org/c/openstack/cloudkitty/+/799207), and Storage state status ( https://review.opendev.org/c/openstack/cloudkitty/+/777442), both of which are already proposed and in the review process. Best regards, -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Tue Aug 24 10:45:07 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Tue, 24 Aug 2021 15:45:07 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hi Karera, Login to master node and check the logs of heat agent in var log. There must be something the cluster is stucking somewhere in creating. Ammad On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: > Hello Ammad, > > I had done as explained and it worked upto a certain point. The master > node was created but the cluster remained in Creation in progress for over > an hour and failed with error below > > Stack Faults > as follows: > default-master > Timed out > default-worker > Timed out > > > Regards > > Tony Karera > > > > > On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: > >> Hi Tony, >> >> You can try by creating your private vxlan network prior to deployment of >> cluster and explicitly create your cluster in vxlan network. >> >> --fixed-network private --fixed-subnet private-subnet >> >> You can specify above while creating a cluster. >> >> Ammad >> >> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >> wrote: >> >>> Hello MOhamed, >>> >>> I think the Kubernetes cluster is ok but it when I deploy it, It creates >>> a fixed network using vlan which I am not using for internal networks. >>> >>> When I create a a vxlan Network and use it in the cluster creation, It >>> fails. Is there a trick around this ? >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >>> >>>> 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. >>>> ------------------------------------------------------------------------------ >>>> >>>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From bharat at stackhpc.com Tue Aug 24 10:45:34 2021 From: bharat at stackhpc.com (Bharat Kunwar) Date: Tue, 24 Aug 2021 11:45:34 +0100 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Were master and worker nodes created? Did you log into the nodes and look at heat container agent logs under /var/log/heat-config/ ? > On 24 Aug 2021, at 11:41, Karera Tony wrote: > > Hello Ammad, > > I had done as explained and it worked upto a certain point. The master node was created but the cluster remained in Creation in progress for over an hour and failed with error below > > Stack Faults > as follows: > default-master > Timed out > default-worker > Timed out > > > Regards > > Tony Karera > > > > > On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed > wrote: > Hi Tony, > > You can try by creating your private vxlan network prior to deployment of cluster and explicitly create your cluster in vxlan network. > > --fixed-network private --fixed-subnet private-subnet > > You can specify above while creating a cluster. > > Ammad > > On Tue, Aug 24, 2021 at 11:59 AM Karera Tony > wrote: > Hello MOhamed, > > I think the Kubernetes cluster is ok but it when I deploy it, It creates a fixed network using vlan which I am not using for internal networks. > > When I create a a vxlan Network and use it in the cluster creation, It fails. Is there a trick around this ? > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 9:00 AM feilong > wrote: > 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. > ------------------------------------------------------------------------------ > > > -- > Regards, > > > Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Tue Aug 24 11:00:26 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 24 Aug 2021 13:00:26 +0200 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: References: Message-ID: I tried again. I started with e new installation of wallaby but this time I used centos source instead of ubuntu source. After first deploy I stared a virtual machine. Then I update the images and I ran a new deploy. Instance went down and in the nova compute log I got the following: https://paste.openstack.org/show/808282/ Ignazio Il giorno mar 24 ago 2021 alle ore 09:02 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello, about the above issue, we discussed on yesterday on openstack-kolla > IRC. > The issue is not related to masakary, but it happens when nova-compute is > redeployed with the following error in > linvirt.log: > 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, > package: 0ubuntu8.12 (Christian Ehrhardt > Tue, 20 Jul 2021 14:13:56 +0200) > 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 > 2021-08-24 06:59:25.012+0000: 3224764: error : > dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary > /usr/sbin/dnsmasq: No such file or directory > 2021-08-24 06:59:25.857+0000: 3224822: error : qemuMonitorOpenUnix:292 : > failed to connect to monitor socket: Connection refused > 2021-08-24 06:59:25.876+0000: 3224821: error : qemuMonitorOpenUnix:292 : > failed to connect to monitor socket: Connection refused > 2021-08-24 06:59:44.670+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-alpha' on this host > 2021-08-24 06:59:44.673+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-arm' on this host > 2021-08-24 06:59:44.674+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-arm' on this host > 2021-08-24 06:59:44.677+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-arm' on this host > 2021-08-24 06:59:44.681+0000: 3224749: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-aarch64' on this host > 2021-08-24 06:59:44.684+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-cris' on this host > 2021-08-24 06:59:44.713+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-lm32' on this host > 2021-08-24 06:59:44.716+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-m68k' on this host > 2021-08-24 06:59:44.719+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-microblaze' on this host > 2021-08-24 06:59:44.721+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-microblazeel' on this host > 2021-08-24 06:59:44.725+0000: 3224749: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-mips' on this host > 2021-08-24 06:59:44.727+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-mipsel' on this host > 2021-08-24 06:59:44.731+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-mips64' on this host > 2021-08-24 06:59:44.733+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-mips64el' on this host > 2021-08-24 06:59:44.736+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc' on this host > 2021-08-24 06:59:44.739+0000: 3224749: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64' on this host > 2021-08-24 06:59:44.741+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64' on this host > 2021-08-24 06:59:44.744+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64' on this host > 2021-08-24 06:59:44.747+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64le' on this host > 2021-08-24 06:59:44.750+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64le' on this host > 2021-08-24 06:59:44.753+0000: 3224749: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-ppc64le' on this host > 2021-08-24 06:59:44.755+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-riscv32' on this host > 2021-08-24 06:59:44.758+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-riscv64' on this host > 2021-08-24 06:59:44.761+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-s390x' on this host > 2021-08-24 06:59:44.763+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-sh4' on this host > 2021-08-24 06:59:44.766+0000: 3224749: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-sh4eb' on this host > 2021-08-24 06:59:44.768+0000: 3224751: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-sparc' on this host > 2021-08-24 06:59:44.771+0000: 3224753: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-sparc64' on this host > 2021-08-24 06:59:44.773+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-unicore32' on this host > 2021-08-24 06:59:44.795+0000: 3224750: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-xtensa' on this host > 2021-08-24 06:59:44.798+0000: 3224752: error : > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > by '/usr/bin/qemu-system-xtensaeb' on this host > > Ignazio > > Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> Hello All, >> I am new in kolla so probably my procedure is not correct. >> Last week I installed wallaby and I deployed on my openstack only two >> virtual machines. >> Today I tried to updated images so: >> >> 1 pulled new images on my local registry >> 2 pushed new images on my local registry >> 3 pushed new images from my local registry to controllers and compute >> nodes >> (kolla-ansible pull --limit control,compute >> 4 run kolla-ansible deploy >> >> All virtual machines went in shutoff state. >> What is wrong in my procedure ? >> >> Regards >> Ignazio >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Tue Aug 24 11:23:54 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Tue, 24 Aug 2021 20:23:54 +0900 Subject: [storlets] Transition stable/stein and older branches to EOL Message-ID: Hi all, I recently noticed that our project still has many old stable branches, from Newton (!!). Because I've never seen any interests to backporting changes to very old branches, I'll propose transitioning stable/stein and older stable branches to EOL. If you have any concerns with that transition please let me know in the following gerrit review. https://review.opendev.org/c/openstack/releases/+/804562 Note that Newton and Ocata will be anywary marked as EOL now since these branches are globally marked as EOL, IIUC. Thank you, Takashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Aug 24 11:35:19 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 24 Aug 2021 12:35:19 +0100 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: References: Message-ID: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> On Tue, 2021-08-24 at 13:00 +0200, Ignazio Cassano wrote: > I tried again. I started with e new installation of wallaby but this time I > used centos source instead of ubuntu source. > After first deploy I stared a virtual machine. > Then I update the images and I ran a new deploy. > Instance went down and in the nova compute log I got the following: > https://paste.openstack.org/show/808282/ i dont know if its the same issue but you might be hitting this https://bugzilla.redhat.com/show_bug.cgi?id=1963164 tl;dr is systemd-machined previously did not work inside the contaiener so livert fell back to its generic cgroups backend, ignoring machined managing mancines without it but recently systemd-machined started working in the contianer. when you upgrade libvirt switches to its machined backend but it does not have the vms registred in that so it stopps them. > > Ignazio > > > Il giorno mar 24 ago 2021 alle ore 09:02 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > > > Hello, about the above issue, we discussed on yesterday on openstack-kolla > > IRC. > > The issue is not related to masakary, but it happens when nova-compute is > > redeployed with the following error in > > linvirt.log: > > 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, > > package: 0ubuntu8.12 (Christian Ehrhardt > > Tue, 20 Jul 2021 14:13:56 +0200) > > 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 > > 2021-08-24 06:59:25.012+0000: 3224764: error : > > dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary > > /usr/sbin/dnsmasq: No such file or directory > > 2021-08-24 06:59:25.857+0000: 3224822: error : qemuMonitorOpenUnix:292 : > > failed to connect to monitor socket: Connection refused > > 2021-08-24 06:59:25.876+0000: 3224821: error : qemuMonitorOpenUnix:292 : > > failed to connect to monitor socket: Connection refused > > 2021-08-24 06:59:44.670+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-alpha' on this host > > 2021-08-24 06:59:44.673+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-arm' on this host > > 2021-08-24 06:59:44.674+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-arm' on this host > > 2021-08-24 06:59:44.677+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-arm' on this host > > 2021-08-24 06:59:44.681+0000: 3224749: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-aarch64' on this host > > 2021-08-24 06:59:44.684+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-cris' on this host > > 2021-08-24 06:59:44.713+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-lm32' on this host > > 2021-08-24 06:59:44.716+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-m68k' on this host > > 2021-08-24 06:59:44.719+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-microblaze' on this host > > 2021-08-24 06:59:44.721+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-microblazeel' on this host > > 2021-08-24 06:59:44.725+0000: 3224749: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-mips' on this host > > 2021-08-24 06:59:44.727+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-mipsel' on this host > > 2021-08-24 06:59:44.731+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-mips64' on this host > > 2021-08-24 06:59:44.733+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-mips64el' on this host > > 2021-08-24 06:59:44.736+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc' on this host > > 2021-08-24 06:59:44.739+0000: 3224749: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64' on this host > > 2021-08-24 06:59:44.741+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64' on this host > > 2021-08-24 06:59:44.744+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64' on this host > > 2021-08-24 06:59:44.747+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64le' on this host > > 2021-08-24 06:59:44.750+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64le' on this host > > 2021-08-24 06:59:44.753+0000: 3224749: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-ppc64le' on this host > > 2021-08-24 06:59:44.755+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-riscv32' on this host > > 2021-08-24 06:59:44.758+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-riscv64' on this host > > 2021-08-24 06:59:44.761+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-s390x' on this host > > 2021-08-24 06:59:44.763+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-sh4' on this host > > 2021-08-24 06:59:44.766+0000: 3224749: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-sh4eb' on this host > > 2021-08-24 06:59:44.768+0000: 3224751: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-sparc' on this host > > 2021-08-24 06:59:44.771+0000: 3224753: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-sparc64' on this host > > 2021-08-24 06:59:44.773+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-unicore32' on this host > > 2021-08-24 06:59:44.795+0000: 3224750: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-xtensa' on this host > > 2021-08-24 06:59:44.798+0000: 3224752: error : > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not supported > > by '/usr/bin/qemu-system-xtensaeb' on this host > > > > Ignazio > > > > Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < > > ignaziocassano at gmail.com> ha scritto: > > > > > Hello All, > > > I am new in kolla so probably my procedure is not correct. > > > Last week I installed wallaby and I deployed on my openstack only two > > > virtual machines. > > > Today I tried to updated images so: > > > > > > 1 pulled new images on my local registry > > > 2 pushed new images on my local registry > > > 3 pushed new images from my local registry to controllers and compute > > > nodes > > > (kolla-ansible pull --limit control,compute > > > 4 run kolla-ansible deploy > > > > > > All virtual machines went in shutoff state. > > > What is wrong in my procedure ? > > > > > > Regards > > > Ignazio > > > > > From ashlee at openstack.org Mon Aug 23 20:33:06 2021 From: ashlee at openstack.org (Ashlee Ferguson) Date: Mon, 23 Aug 2021 15:33:06 -0500 Subject: OpenInfra Live - August 26, 2021 at 9am CT Message-ID: Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack community. When we talk about Large Scale, it usually refers to scaling out to hundreds of thousands of commodity nodes. But there is another dimension to Large Scale OpenStack: using OpenStack to build supercomputers to use in research and HPC. In this episode, operators of OpenStack supercomputers and HPC centers will discuss the unique challenges this use case brings. Episode: Large Scale OpenStack: Discussing software-defined supercomputers Date and time: August 26, 2021 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=fOJTHanmOFg LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6834150009706037248/ Facebook: https://www.facebook.com/104139126308032/posts/4256168904438346/ WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Stig Telfer, StackHPC Sadaf Alam, Swiss National Supercomputer Centre Jonathan Mills, NASA Goddard Space Flight Center Steve Quenette, Monash e-Research Centre Happy Sithole, Center for High Performance Computing in South Africa 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 wodel.youchi at gmail.com Tue Aug 24 07:59:49 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 24 Aug 2021 08:59:49 +0100 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hi, and thanks for your help As for Ceph, here is container prepare parameter_defaults: ContainerImagePrepare: - push_destination: true set: ceph_alertmanager_image: alertmanager ceph_alertmanager_namespace: quay.ceph.io/prometheus ceph_alertmanager_tag: v0.16.2 ceph_grafana_image: grafana ceph_grafana_namespace: quay.ceph.io/app-sre *ceph_grafana_tag: 5.4.3* ceph_image: daemon ceph_namespace: quay.ceph.io/ceph-ci ceph_node_exporter_image: node-exporter ceph_node_exporter_namespace: quay.ceph.io/prometheus ceph_node_exporter_tag: v0.17.0 ceph_prometheus_image: prometheus ceph_prometheus_namespace: quay.ceph.io/prometheus ceph_prometheus_tag: v2.7.2 *ceph_tag: v4.0.19-stable-4.0-nautilus-centos-7-x86_64* name_prefix: centos-binary- name_suffix: '' namespace: quay.io/tripleotraincentos8 neutron_driver: ovn rhel_containers: false tag: current-tripleo tag_from_label: rdo_version And yes, the 10.200.7.0/24 network is my storage network Here is a snippet from my network_data.yaml - name: Storage vip: true vlan: 1107 name_lower: storage ip_subnet: '10.200.7.0/24' allocation_pools: [{'start': '10.200.7.150', 'end': '10.200.7.169'}] I will look into the grafana service to see why it's not booting and get back to you. Regards. Le lun. 23 août 2021 à 17:28, Francesco Pantano a écrit : > Hello, > thanks John for your reply here. > A few more comments inline: > > On Mon, Aug 23, 2021 at 6:16 PM John Fulton wrote: > >> On Mon, Aug 23, 2021 at 10:52 AM wodel youchi >> wrote: >> > >> > Hi, >> > >> > I redid the undercloud deployment for the Train version for now. And I >> verified the download URL for the images. >> > My overcloud deployment has moved forward but I still get errors. >> > >> > This is what I got this time : >> >> >> >> "TASK [ceph-grafana : wait for grafana to start] >> ********************************", >> >> "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) >> 0:12:59.319 ********* ", >> >> "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": >> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> >> 0.7.151:3100\"}", >> >> "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": >> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> >> 0.7.155:3100\"}", >> >> "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": >> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >> >> 0.7.165:3100\"}", >> >> I'm not certain of the ceph-ansible version you're using but it should >> be a version 4 with train. ceph-ansible should already be installed on >> your undercloud judging by this error and in the latest version 4 this >> task is where it failed: >> >> >> https://github.com/ceph/ceph-ansible/blob/v4.0.64/roles/ceph-grafana/tasks/configure_grafana.yml#L112-L115 >> >> You can check the status of this service on your three controllers and >> then debug it directly. > > As John pointed out, ceph-ansible is able to configure, render and start > the associated > systemd unit for all the ceph monitoring stack components (node-exported, > prometheus, alertmanager and > grafana). > You can ssh to your controllers, and check the systemd unit associated, > checking the journal to see why > they failed to start (I saw there's a timeout waiting for the container to > start). > A potential plan, in this case, could be: > > 1. check the systemd unit (I guess you can start with grafana which is the > failed service) > 2. look at the journal logs (feel free to attach here the relevant part of > the output) > 3. double check the network where the service is bound (can you attach the > /var/lib/mistral//ceph-ansible/group_vars/all.yaml) > * The grafana process should be run on the storage network, but I see > a "Timeout when waiting for 10.200.7.165:3100": is that network the right > one? > >> > > >> John >> >> >> "RUNNING HANDLER [ceph-prometheus : service handler] >> ****************************", >> >> "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) >> 0:18:00.087 ********* ", >> >> "PLAY RECAP >> *********************************************************************", >> >> "overcloud-computehci-0 : ok=224 changed=23 >> unreachable=0 failed=0 skipped=415 rescued=0 ignored=0 ", >> >> "overcloud-computehci-1 : ok=199 changed=18 >> unreachable=0 failed=0 skipped=392 rescued=0 ignored=0 ", >> >> "overcloud-computehci-2 : ok=212 changed=23 >> unreachable=0 failed=0 skipped=390 rescued=0 ignored=0 ", >> >> "overcloud-controller-0 : ok=370 changed=52 >> unreachable=0 failed=1 skipped=539 rescued=0 ignored=0 ", >> >> "overcloud-controller-1 : ok=308 changed=43 >> unreachable=0 failed=1 skipped=495 rescued=0 ignored=0 ", >> >> "overcloud-controller-2 : ok=317 changed=45 >> unreachable=0 failed=1 skipped=493 rescued=0 ignored=0 ", >> >> >> >> "INSTALLER STATUS >> ***************************************************************", >> >> "Install Ceph Monitor : Complete (0:00:52)", >> >> "Install Ceph Manager : Complete (0:05:49)", >> >> "Install Ceph OSD : Complete (0:02:28)", >> >> "Install Ceph RGW : Complete (0:00:27)", >> >> "Install Ceph Client : Complete (0:00:33)", >> >> "Install Ceph Grafana : In Progress (0:05:54)", >> >> "\tThis phase can be restarted by running: >> roles/ceph-grafana/tasks/main.yml", >> >> "Install Ceph Node Exporter : Complete (0:00:28)", >> >> "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) >> 0:18:00.094 ********* ", >> >> >> "=============================================================================== >> ", >> >> "ceph-grafana : wait for grafana to start >> ------------------------------ 300.77s", >> >> "ceph-facts : get ceph current status >> ---------------------------------- 300.27s", >> >> "ceph-container-common : pulling >> udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 >> >> image -- 19.04s", >> >> "ceph-mon : waiting for the monitor(s) to form the quorum... >> ------------ 12.83s", >> >> "ceph-osd : use ceph-volume lvm batch to create bluestore osds >> ---------- 12.13s", >> >> "ceph-osd : wait for all osd to be up >> ----------------------------------- 11.88s", >> >> "ceph-osd : set pg_autoscale_mode value on pool(s) >> ---------------------- 11.00s", >> >> "ceph-osd : create openstack pool(s) >> ------------------------------------ 10.80s", >> >> "ceph-grafana : make sure grafana is down >> ------------------------------- 10.66s", >> >> "ceph-osd : customize pool crush_rule >> ----------------------------------- 10.15s", >> >> "ceph-osd : customize pool size >> ----------------------------------------- 10.15s", >> >> "ceph-osd : customize pool min_size >> ------------------------------------- 10.14s", >> >> "ceph-osd : assign application to pool(s) >> ------------------------------- 10.13s", >> >> "ceph-osd : list existing pool(s) >> ---------------------------------------- 8.59s", >> >> >> >> "ceph-mon : fetch ceph initial keys >> -------------------------------------- 7.01s", >> >> "ceph-container-common : get ceph version >> -------------------------------- 6.75s", >> >> "ceph-prometheus : start prometheus services >> ----------------------------- 6.67s", >> >> "ceph-mgr : wait for all mgr to be up >> ------------------------------------ 6.66s", >> >> "ceph-grafana : start the grafana-server service >> ------------------------- 6.33s", >> >> "ceph-mgr : create ceph mgr keyring(s) on a mon node >> --------------------- 6.26s" >> >> ], >> >> "failed_when_result": true >> >> } >> >> 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | >> TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ >> >> in case of failure | undercloud | 0:37:30.226345 | 0.25s >> >> >> >> PLAY RECAP >> ********************************************************************* >> >> overcloud-computehci-0 : ok=213 changed=117 unreachable=0 >> failed=0 skipped=120 rescued=0 ignored=0 >> >> overcloud-computehci-1 : ok=207 changed=117 unreachable=0 >> failed=0 skipped=120 rescued=0 ignored=0 >> >> overcloud-computehci-2 : ok=207 changed=117 unreachable=0 >> failed=0 skipped=120 rescued=0 ignored=0 >> >> overcloud-controller-0 : ok=237 changed=145 unreachable=0 >> failed=0 skipped=128 rescued=0 ignored=0 >> >> overcloud-controller-1 : ok=232 changed=145 unreachable=0 >> failed=0 skipped=128 rescued=0 ignored=0 >> >> overcloud-controller-2 : ok=232 changed=145 unreachable=0 >> failed=0 skipped=128 rescued=0 ignored=0 >> >> undercloud : ok=100 changed=18 unreachable=0 >> failed=1 skipped=37 rescued=0 ignored=0 >> >> >> >> 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >> Tasks: 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed >> Time: 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.560490 | UUID | >> Info | Host | Task Name | Run Time >> >> 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | >> SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans >> >> ible | 1082.71s >> >> 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | >> SUMMARY | overcloud-controller-1 | Wait for container-puppet t >> >> asks (generate config) to finish | 356.02s >> >> 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | >> SUMMARY | overcloud-controller-0 | Wait for container-puppet t >> >> asks (generate config) to finish | 355.74s >> >> 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | >> SUMMARY | overcloud-controller-2 | Wait for container-puppet t >> >> asks (generate config) to finish | 355.68s >> >> 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | >> SUMMARY | undercloud | Run tripleo-container-image-prepare log >> >> ged to: /var/log/tripleo-container-image-prepare.log | 143.03s >> >> 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | >> SUMMARY | overcloud-controller-0 | Wait for puppet host config >> >> uration to finish | 125.36s >> >> 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | >> SUMMARY | overcloud-controller-2 | Wait for puppet host config >> >> uration to finish | 125.33s >> >> 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | >> SUMMARY | overcloud-controller-1 | Wait for puppet host config >> >> uration to finish | 125.25s >> >> 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | >> SUMMARY | overcloud-controller-2 | Run puppet on the host to a >> >> pply IPtables rules | 108.08s >> >> 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | >> SUMMARY | overcloud-controller-0 | Run puppet on the host to a >> >> pply IPtables rules | 107.34s >> >> 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | >> SUMMARY | overcloud-computehci-2 | Wait for container-puppet t >> >> asks (generate config) to finish | 96.56s >> >> 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | >> SUMMARY | overcloud-computehci-0 | Wait for container-puppet t >> >> asks (generate config) to finish | 96.38s >> >> 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | >> SUMMARY | overcloud-computehci-1 | Wait for container-puppet t >> >> asks (generate config) to finish | 93.41s >> >> 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | >> SUMMARY | overcloud-computehci-0 | Pre-fetch all the container >> >> s | 92.70s >> >> 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | >> SUMMARY | overcloud-computehci-2 | Pre-fetch all the container >> >> s | 91.90s >> >> 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | >> SUMMARY | overcloud-computehci-1 | Pre-fetch all the container >> >> s | 91.88s >> >> 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | >> SUMMARY | overcloud-computehci-1 | Wait for puppet host config >> >> uration to finish | 90.37s >> >> 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | >> SUMMARY | overcloud-computehci-2 | Wait for puppet host config >> >> uration to finish | 90.37s >> >> 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | >> SUMMARY | overcloud-computehci-0 | Wait for puppet host config >> >> uration to finish | 90.35s >> >> 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State >> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes which >> did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >> >> 2021-08-23 15:00:24.562379 | The following node(s) had failures: >> undercloud >> >> 2021-08-23 15:00:24.562456 | >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts >> >> Ansible failed, check log at >> /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: >> http://10.0.2.40:5000 >> >> Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard >> >> Overcloud rc file: /home/stack/overcloudrc >> >> Overcloud Deployed with error >> >> Overcloud configuration failed. >> >> >> > >> > >> > Could someone help debug this, the ansible.log is huge, I can't see >> what's the origin of the problem, if someone can point me to the right >> direction it will aprecciated. >> > Thanks in advance. >> > >> > Regards. >> > >> > Le mer. 18 août 2021 à 18:02, Wesley Hayutin a >> écrit : >> >> >> >> >> >> >> >> 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 >> >> >> > > -- > Francesco Pantano > GPG KEY: F41BD75C > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Tue Aug 24 10:32:31 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 24 Aug 2021 11:32:31 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: Hi again, Here is the error I am getting when trying to generate the *overcloud-baremetal-deployed.yaml *file : CMD : openstack overcloud node provision --stack overcloud --network-config --output ~/templates/overcloud-baremetal-deployed.yaml ~/templates/baremetal_deployment.yaml Error : > > > > > > > > > > > *The full traceback is: > > File > "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", > line 601, in run_module > File > "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", > line 494, in manage_instances_ports File > "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run > result = self.fn(*self.args, **self.kwargs) File > "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", > line 385, in _provision_ports File > "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", > line 319, in generate_port_defs* > ], > "template": > "/home/stack/templates/nic-configs/bonds_vlans.j2" > }, > "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" > }, > { > > [215/1899] > "network": "tenant", > "subnet": "tenant_subnet01" > }, > { > "network": "ctlplane", > "vif": true > } > ], > "nics": [ > { > "network": "ctlplane" > } > ], > "ssh_public_keys": "ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAAAgQDdFv9qwUs3x6egY5Xke3gh2O8CnXTJ2h2jRpWYEFzL1fyZrMKykMBUEfbkQGYzONsE29/BpS265Df4RgZB3eHx4KWcaskSwjl > DaUzxP0ZsSl2MzxtDIqE3UTrsmivNGx0ungcTorOc96V9daqU/Vu2HU8J+YEA6+OjddPX1ngz/w== > root at undercloud.umaitek.dz ", > "user_name": "heat-admin" > }, > { > "capabilities": { > "profile": "computeHCI" > }, > "config_drive": { > "meta_data": { > "instance-type": "ComputeHCI" > } > }, > "hostname": "computehci-0", > "image": { > "href": > "file:///var/lib/ironic/images/overcloud-full.raw", > "kernel": > "file:///var/lib/ironic/images/overcloud-full.vmlinuz", > "ramdisk": > "file:///var/lib/ironic/images/overcloud-full.initrd" > }, > "network_config": { > "template": > "/home/stack/templates/nic-configs/bonds_vlans.j2" > }, > "networks": [ > "network": "internal_api", > "subnet": "internal_api_subnet02" > }, > { > "network": "tenant", > "subnet": "tenant_subnet02" > }, > { > "network": "storage", > "subnet": "storage_subnet02" > }, > { > "network": "storage_mgmt", > "subnet": "storage_mgmt_subnet02" > 2021-08-24 10:21:18.492374 | > 52540075-9baf-0191-8598-000000000019 | FATAL | Provision instance > network ports | localhost | error={ > "changed": true, > "error": "'internal_api_subnet02'", > "invocation": { > "module_args": { > "api_timeout": null, > "auth": null, > "auth_type": null, > "availability_zone": null, > "ca_cert": null, > "client_cert": null, > "client_key": null, > "concurrency": 2, > "hostname_role_map": { > "computehci-0": "ComputeHCI", > "controller-0": "Controller" > }, > ... > ... > ... > "provisioned_instances": [ > > [38/1899] > { > "hostname": "controller-0", > "id": "1dff400f-0dd1-4eb0-b4c1-84397d387a4a", > "name": "controller0" > }, > { > "hostname": "computehci-0", > "id": "3d6c399f-53b7-472b-b784-67193a485e43", > "name": "computeHCI0" > } > ], > "region_name": null, > "stack_name": "overcloud", > "state": "present", > "timeout": 180, > "validate_certs": null, > "wait": true > } > > > > > * }, "msg": "Error managing network ports 'internal_api_subnet02'", > "node_port_map": {}, "success": false}* > 2021-08-24 10:21:18.494473 | 52540075-9baf-0191-8598-000000000019 | > TIMING | Provision instance network ports | localhost | 0:04:58.315416 | > 3.72s > > NO MORE HOSTS LEFT > ************************************************************* > > PLAY RECAP > ********************************************************************* > localhost : ok=10 changed=3 unreachable=0 > failed=1 skipped=5 rescued=0 ignored=0 > 2021-08-24 10:21:18.498948 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.499338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Tasks: > 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.499755 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: > 0:04:58.320717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.500105 | UUID | > Info | Host | Task Name | Run Time > 2021-08-24 10:21:18.500449 | 52540075-9baf-0191-8598-000000000017 | > SUMMARY | localhost | Provision instances | 285.25s > 2021-08-24 10:21:18.500868 | 52540075-9baf-0191-8598-000000000014 | > SUMMARY | localhost | Reserve instances | 6.08s > 2021-08-24 10:21:18.501228 | 52540075-9baf-0191-8598-000000000019 | > SUMMARY | localhost | Provision instance network ports | 3.72s > 2021-08-24 10:21:18.501588 | 52540075-9baf-0191-8598-000000000013 | > SUMMARY | localhost | Find existing instances | 1.52s > 2021-08-24 10:21:18.501944 | 52540075-9baf-0191-8598-000000000012 | > SUMMARY | localhost | Expand roles | 0.92s > 2021-08-24 10:21:18.502281 | 52540075-9baf-0191-8598-00000000000c | > SUMMARY | localhost | stat overcloud-full.raw | 0.26s > 2021-08-24 10:21:18.502706 | 52540075-9baf-0191-8598-00000000000d | > SUMMARY | localhost | stat overcloud-full.initrd | 0.19s > 2021-08-24 10:21:18.503053 | 52540075-9baf-0191-8598-00000000000e | > SUMMARY | localhost | Set file based default image | 0.04s > 2021-08-24 10:21:18.503419 | 52540075-9baf-0191-8598-000000000018 | > SUMMARY | localhost | Metalsmith log for provision instances | 0.04s > 2021-08-24 10:21:18.503806 | 52540075-9baf-0191-8598-000000000016 | > SUMMARY | localhost | Set concurrency fact | 0.04s > 2021-08-24 10:21:18.504139 | 52540075-9baf-0191-8598-000000000015 | > SUMMARY | localhost | Metalsmith log for reserve instances | 0.04s > 2021-08-24 10:21:18.504469 | 52540075-9baf-0191-8598-00000000000f | > SUMMARY | localhost | Set whole-disk file based default image | 0.03s > 2021-08-24 10:21:18.504849 | 52540075-9baf-0191-8598-000000000010 | > SUMMARY | localhost | Set glance based default image | 0.03s > 2021-08-24 10:21:18.505246 | 52540075-9baf-0191-8598-000000000009 | > SUMMARY | localhost | fail | 0.03s > 2021-08-24 10:21:18.505627 | 52540075-9baf-0191-8598-000000000008 | > SUMMARY | localhost | fail | 0.03s > 2021-08-24 10:21:18.505987 | 52540075-9baf-0191-8598-00000000000a | > SUMMARY | localhost | fail | 0.02s > 2021-08-24 10:21:18.506315 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.506693 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.507032 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did > not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ > 2021-08-24 10:21:18.507351 | The following node(s) had failures: localhost > 2021-08-24 10:21:18.507720 | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Temporary directory [ /tmp/tripleob9lxg9vi ] cleaned up > Ansible execution failed. playbook: > /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run > Status: failed, Return Code: 2 > Temporary directory [ /tmp/tripleoyso22wsn ] cleaned up > Exception occured while running the command > Traceback (most recent call last): > File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line > 34, in run > super(Command, self).run(parsed_args) > File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", line > 39, in run > return super(Command, self).run(parsed_args) > File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, in > run > return_code = self.take_action(parsed_args) or 0 > File > "/usr/lib/python3.6/site-packages/tripleoclient/v2/overcloud_node.py", line > 323, in take_action > extra_vars=extra_vars, > File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line > 724, in run_ansible_playbook > raise RuntimeError(err_msg) > RuntimeError: Ansible execution failed. playbook: > /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run > Status: failed, Return Code: 2 > Ansible execution failed. playbook: > /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run > Status: failed, Return Code: 2 > clean_up ProvisionNode: Ansible execution failed. playbook: > /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run > Status: failed, Return Code: 2 > END return value: 1 > Here is my baremetal_deployment.yaml file : > - name: Controller > count: 1 > hostname_format: controller-%index% > 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: /home/stack/templates/nic-configs/bonds_vlans.j2 > default_route_network: > - external > - name: ComputeHCI > count: 1 > hostname_format: computehci-%index% > defaults: > profile: computeHCI > networks: > - network: internal_api > subnet: internal_api_subnet02 > - network: tenant > subnet: tenant_subnet02 > - network: storage > subnet: storage_subnet02 > - network: storage_mgmt > subnet: storage_mgmt_subnet02 > network_config: > template: /home/stack/templates/nic-configs/bonds_vlans.j2 > If someone can help me and point me where to look. Any help will be appreciated. Regards. Le lun. 23 août 2021 à 12:48, wodel youchi a écrit : > 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 ignaziocassano at gmail.com Tue Aug 24 11:47:46 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 24 Aug 2021 13:47:46 +0200 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> References: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> Message-ID: Hello Sean, I do not know what is "systemd-machined". My compute nodes are ubuntu 20.40, while images are centos source wallaby. Reading the logs is sure that nova compute lost connection with libvirtd, but in a installation where containers are not used (no kolla) this does not happen. What I must check, please ? Is the above bug considered still opened ? Ignazio Il giorno mar 24 ago 2021 alle ore 13:35 Sean Mooney ha scritto: > On Tue, 2021-08-24 at 13:00 +0200, Ignazio Cassano wrote: > > I tried again. I started with e new installation of wallaby but this > time I > > used centos source instead of ubuntu source. > > After first deploy I stared a virtual machine. > > Then I update the images and I ran a new deploy. > > Instance went down and in the nova compute log I got the following: > > https://paste.openstack.org/show/808282/ > > i dont know if its the same issue but you might be hitting this > https://bugzilla.redhat.com/show_bug.cgi?id=1963164 > tl;dr is systemd-machined previously did not work inside the contaiener so > livert fell > back to its generic cgroups backend, ignoring machined managing mancines > without it but recently systemd-machined started > working in the contianer. when you upgrade libvirt switches to its > machined backend but it does not have the vms registred in that > so it stopps them. > > > > > > Ignazio > > > > > > Il giorno mar 24 ago 2021 alle ore 09:02 Ignazio Cassano < > > ignaziocassano at gmail.com> ha scritto: > > > > > Hello, about the above issue, we discussed on yesterday on > openstack-kolla > > > IRC. > > > The issue is not related to masakary, but it happens when nova-compute > is > > > redeployed with the following error in > > > linvirt.log: > > > 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, > > > package: 0ubuntu8.12 (Christian Ehrhardt < > christian.ehrhardt at canonical.com> > > > Tue, 20 Jul 2021 14:13:56 +0200) > > > 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 > > > 2021-08-24 06:59:25.012+0000: 3224764: error : > > > dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary > > > /usr/sbin/dnsmasq: No such file or directory > > > 2021-08-24 06:59:25.857+0000: 3224822: error : qemuMonitorOpenUnix:292 > : > > > failed to connect to monitor socket: Connection refused > > > 2021-08-24 06:59:25.876+0000: 3224821: error : qemuMonitorOpenUnix:292 > : > > > failed to connect to monitor socket: Connection refused > > > 2021-08-24 06:59:44.670+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-alpha' on this host > > > 2021-08-24 06:59:44.673+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.674+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.677+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.681+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-aarch64' on this host > > > 2021-08-24 06:59:44.684+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-cris' on this host > > > 2021-08-24 06:59:44.713+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-lm32' on this host > > > 2021-08-24 06:59:44.716+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-m68k' on this host > > > 2021-08-24 06:59:44.719+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-microblaze' on this host > > > 2021-08-24 06:59:44.721+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-microblazeel' on this host > > > 2021-08-24 06:59:44.725+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips' on this host > > > 2021-08-24 06:59:44.727+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mipsel' on this host > > > 2021-08-24 06:59:44.731+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips64' on this host > > > 2021-08-24 06:59:44.733+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips64el' on this host > > > 2021-08-24 06:59:44.736+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc' on this host > > > 2021-08-24 06:59:44.739+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.741+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.744+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.747+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.750+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.753+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.755+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-riscv32' on this host > > > 2021-08-24 06:59:44.758+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-riscv64' on this host > > > 2021-08-24 06:59:44.761+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-s390x' on this host > > > 2021-08-24 06:59:44.763+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sh4' on this host > > > 2021-08-24 06:59:44.766+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sh4eb' on this host > > > 2021-08-24 06:59:44.768+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sparc' on this host > > > 2021-08-24 06:59:44.771+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sparc64' on this host > > > 2021-08-24 06:59:44.773+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-unicore32' on this host > > > 2021-08-24 06:59:44.795+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-xtensa' on this host > > > 2021-08-24 06:59:44.798+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-xtensaeb' on this host > > > > > > Ignazio > > > > > > Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < > > > ignaziocassano at gmail.com> ha scritto: > > > > > > > Hello All, > > > > I am new in kolla so probably my procedure is not correct. > > > > Last week I installed wallaby and I deployed on my openstack only > two > > > > virtual machines. > > > > Today I tried to updated images so: > > > > > > > > 1 pulled new images on my local registry > > > > 2 pushed new images on my local registry > > > > 3 pushed new images from my local registry to controllers and compute > > > > nodes > > > > (kolla-ansible pull --limit control,compute > > > > 4 run kolla-ansible deploy > > > > > > > > All virtual machines went in shutoff state. > > > > What is wrong in my procedure ? > > > > > > > > Regards > > > > Ignazio > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.slagle at gmail.com Tue Aug 24 12:13:46 2021 From: james.slagle at gmail.com (James Slagle) Date: Tue, 24 Aug 2021 08:13:46 -0400 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga Message-ID: I'm submitting my candidacy for TripleO PTL. I look forward to the opportunity to help the community as we tackle some of our upcoming challenges — the transition to CentOS/RHEL 9, increasing complexity around container management, and revisiting our commitments to our adopted tooling. I'd suggest that to assist with these efforts, we focus on our review prioritization and in progress work streams. I would like to see folks representing review priorities during the TripleO meeting and on an etherpad. I'd also like to see less parallel streams of work, with the opportunity for more folks to collaborate on common priorities. If elected as PTL, I would plan to organize the efforts around such an approach. Thank you for the consideration. https://review.opendev.org/c/openstack/election/+/805840 -- -- James Slagle -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Aug 24 12:16:27 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 24 Aug 2021 14:16:27 +0200 Subject: [infra][devstack][CI] pmlogger service fails to start Message-ID: Hi, Is there any work ongoing to figure out why devstack fails with? Job for pmlogger.service failed because a timeout was exceeded. We have 120 hits in the last 7 days. Recent example [1], logstash signature [2]. cheers, gibi [1] https://zuul.opendev.org/t/openstack/build/a36289ff4fc34b18af70b5b29d38bdf4/log/job-output.txt#3866 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Job%20for%20pmlogger.service%20failed%20because%20a%20timeout%20was%20exceeded.%5C%22 From whayutin at redhat.com Tue Aug 24 12:26:06 2021 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 24 Aug 2021 06:26:06 -0600 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: On Tue, Aug 24, 2021 at 6:23 AM James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- > +2 Thanks James! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpeacock at redhat.com Tue Aug 24 12:36:05 2021 From: dpeacock at redhat.com (David Peacock) Date: Tue, 24 Aug 2021 08:36:05 -0400 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 On Tue, Aug 24, 2021 at 8:16 AM James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfidente at redhat.com Tue Aug 24 13:08:09 2021 From: gfidente at redhat.com (Giulio Fidente) Date: Tue, 24 Aug 2021 15:08:09 +0200 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: On 8/24/21 2:13 PM, James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle > some of our upcoming challenges — the transition to CentOS/RHEL 9, > increasing complexity around container management, and revisiting our > commitments to our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad.  I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. +1 from me, especially on using the meeting to discuss review priorities and and as a way to get people collaborate on common priorities > If elected as PTL, I would plan to organize the efforts around such an > approach. > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > thank you for the candidature -- Giulio Fidente GPG KEY: 08D733BA From kevin at cloudnull.com Tue Aug 24 13:09:35 2021 From: kevin at cloudnull.com (Carter, Kevin) Date: Tue, 24 Aug 2021 08:09:35 -0500 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 -- Kevin Carter IRC: Cloudnull On Tue, Aug 24, 2021 at 7:24 AM James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpodivin at redhat.com Tue Aug 24 13:17:15 2021 From: jpodivin at redhat.com (Jiri Podivin) Date: Tue, 24 Aug 2021 15:17:15 +0200 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 On Tue, Aug 24, 2021 at 3:13 PM Carter, Kevin wrote: > +2 > > -- > > Kevin Carter > IRC: Cloudnull > > > On Tue, Aug 24, 2021 at 7:24 AM James Slagle > wrote: > >> I'm submitting my candidacy for TripleO PTL. >> >> I look forward to the opportunity to help the community as we tackle some >> of our upcoming challenges — the transition to CentOS/RHEL 9, increasing >> complexity around container management, and revisiting our commitments to >> our adopted tooling. >> >> I'd suggest that to assist with these efforts, we focus on our review >> prioritization and in progress work streams. I would like to see folks >> representing review priorities during the TripleO meeting and on an >> etherpad. I'd also like to see less parallel streams of work, with the >> opportunity for more folks to collaborate on common priorities. >> >> If elected as PTL, I would plan to organize the efforts around such an >> approach. >> >> Thank you for the consideration. >> >> https://review.opendev.org/c/openstack/election/+/805840 >> >> -- >> -- James Slagle >> -- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpantano at redhat.com Tue Aug 24 13:17:39 2021 From: fpantano at redhat.com (Francesco Pantano) Date: Tue, 24 Aug 2021 15:17:39 +0200 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 thanks! On Tue, Aug 24, 2021 at 3:14 PM Giulio Fidente wrote: > On 8/24/21 2:13 PM, James Slagle wrote: > > I'm submitting my candidacy for TripleO PTL. > > > > I look forward to the opportunity to help the community as we tackle > > some of our upcoming challenges — the transition to CentOS/RHEL 9, > > increasing complexity around container management, and revisiting our > > commitments to our adopted tooling. > > > > I'd suggest that to assist with these efforts, we focus on our review > > prioritization and in progress work streams. I would like to see folks > > representing review priorities during the TripleO meeting and on an > > etherpad. I'd also like to see less parallel streams of work, with the > > opportunity for more folks to collaborate on common priorities. > > +1 from me, especially on using the meeting to discuss review priorities > and and as a way to get people collaborate on common priorities > > > If elected as PTL, I would plan to organize the efforts around such an > > approach. > > Thank you for the consideration. > > > > https://review.opendev.org/c/openstack/election/+/805840 > > > > thank you for the candidature > -- > Giulio Fidente > GPG KEY: 08D733BA > > > -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: From ykarel at redhat.com Tue Aug 24 13:26:10 2021 From: ykarel at redhat.com (Yatin Karel) Date: Tue, 24 Aug 2021 18:56:10 +0530 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 On Tue, Aug 24, 2021 at 5:53 PM James Slagle wrote: > > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some of our upcoming challenges — the transition to CentOS/RHEL 9, increasing complexity around container management, and revisiting our commitments to our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review prioritization and in progress work streams. I would like to see folks representing review priorities during the TripleO meeting and on an etherpad. I'd also like to see less parallel streams of work, with the opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an approach. > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- From gfidente at redhat.com Tue Aug 24 13:27:19 2021 From: gfidente at redhat.com (Giulio Fidente) Date: Tue, 24 Aug 2021 15:27:19 +0200 Subject: [election][manila][ptl] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: <55b3f3cd-62a6-b398-31b2-e81ea9de93b5@redhat.com> On 8/24/21 8:34 AM, Goutham Pacha Ravi wrote: > Hello fellow zorillas and other interested stackers, > > I'm expressing interest to continue serving as PTL for the OpenStack > Manila team through the Yoga cycle. I've used my great privilege in this > role to affect the community in many small and significant ways over the > past four cycles. It has been a smooth ride because of stellar > contributors who're beyond motivated and enthusiastic to develop and > maintain impactful software while having fun. The enthusiasm is > bolstered by grit to be a team with a difference. We jump at the > opportunity to help a user or mentor and welcome new contributors or > back each other up and help get stuff done, regardless of the "barriers" > of affiliation. I enjoy being the occasional enabler to this camaraderie. > > During the Xena cycle, we mentored two Outreachy interns and on-boarded > several new contributors. We added sub team core maintainers in the > manila-tempest-plugin project and a new core maintainer across the > manila repos. We drove down bug backlogs through bug squash weeks, > swarmed to work on the OpenStackClient with a hack-a-thon and crushed > the goal to drive down tech debt. We kept the momentum on several > multi-cycle efforts such as OpenStackSDK integration, Secure RBAC, > Active/Active HA. The Yoga cycle will be critical in our efforts to > drive some of these multi-cycle efforts to closure. thanks Goutham for caring about the community and for pushing forward complex core enhancements > So, if you will have me, I wish to serve you through the Yoga cycle and > get things done. I would tell you it's going to be the best release > ever; but I would hold out the distinction for the Zorilla cycle - yes > that's what we'll name it, what other cool name will we have anyway :) -- Giulio Fidente GPG KEY: 08D733BA From tpb at dyncloud.net Tue Aug 24 13:44:02 2021 From: tpb at dyncloud.net (Tom Barron) Date: Tue, 24 Aug 2021 09:44:02 -0400 Subject: [election][manila][ptl] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: +2 from me. Thanks, Goutham for your amazing leadership. I'm delighted that you will continue to serve as PTL! On Tue, Aug 24, 2021 at 2:34 AM Goutham Pacha Ravi wrote: > Hello fellow zorillas and other interested stackers, > > I'm expressing interest to continue serving as PTL for the OpenStack > Manila team through the Yoga cycle. I've used my great privilege in this > role to affect the community in many small and significant ways over the > past four cycles. It has been a smooth ride because of stellar contributors > who're beyond motivated and enthusiastic to develop and maintain impactful > software while having fun. The enthusiasm is bolstered by grit to be a team > with a difference. We jump at the opportunity to help a user or mentor and > welcome new contributors or back each other up and help get stuff done, > regardless of the "barriers" of affiliation. I enjoy being the occasional > enabler to this camaraderie. > > During the Xena cycle, we mentored two Outreachy interns and on-boarded > several new contributors. We added sub team core maintainers in the > manila-tempest-plugin project and a new core maintainer across the manila > repos. We drove down bug backlogs through bug squash weeks, swarmed to work > on the OpenStackClient with a hack-a-thon and crushed the goal to drive > down tech debt. We kept the momentum on several multi-cycle efforts such as > OpenStackSDK integration, Secure RBAC, Active/Active HA. The Yoga cycle > will be critical in our efforts to drive some of these multi-cycle efforts > to closure. > > So, if you will have me, I wish to serve you through the Yoga cycle and > get things done. I would tell you it's going to be the best release ever; > but I would hold out the distinction for the Zorilla cycle - yes that's > what we'll name it, what other cool name will we have anyway :) > > Thank you for your support, > Goutham Pacha Ravi > IRC: gouthamr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Tue Aug 24 14:18:23 2021 From: mthode at mthode.org (Matthew Thode) Date: Tue, 24 Aug 2021 09:18:23 -0500 Subject: [election][requirements][ptl] PTL Candidacy for Yoga Message-ID: <20210824141823.niz7vrsqhe2nj653@mthode.org> I would like to announce my candidacy for PTL of the Requirements project for the Yoga cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like prettytable). 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. I look forward to continue working with you in this cycle, as your PTL or not. IRC: prometheanfire -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From marios at redhat.com Tue Aug 24 14:19:21 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 24 Aug 2021 17:19:21 +0300 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: great news thanks Slagle On Tuesday, August 24, 2021, James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- > -- _sent from my mobile - sorry for spacing spelling etc_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Tue Aug 24 14:22:59 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Tue, 24 Aug 2021 22:22:59 +0800 Subject: What is this error, does it effect the install? Message-ID: <01de01d798f3$8b7403b0$a25c0b10$@163.com> I try to install Openstack using kolla, but it's a error when I check the system before installation : # kolla-ansible -i ./multinode prechecks PLAY RECAP **************************************************************************** *********************************** compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 The error is : The full traceback is: Traceback (most recent call last): File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/Ans iballZ_kolla_container_facts.py", line 102, in _ansiballz_main() File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/Ans iballZ_kolla_container_facts.py", line 94, in _ansiballz_main invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/Ans iballZ_kolla_container_facts.py", line 40, in invoke_module runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True) File "/usr/lib64/python3.6/runpy.py", line 205, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container _facts_payload.zip/ansible/modules/kolla_container_facts.py", line 18, in ModuleNotFoundError: No module named 'docker' fatal: [localhost]: FAILED! => { "changed": false, "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/An siballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/An siballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/An siballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_containe r_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1 } I installed the docker package on the deploy localhost and run again, but it still raise the same error. What is it ? And does it effect the install ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeepggn93 at gmail.com Tue Aug 24 14:18:03 2021 From: sandeepggn93 at gmail.com (Sandeep Yadav) Date: Tue, 24 Aug 2021 19:48:03 +0530 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: Hello, To me it looks like the example shared in the documentation[1] is for leaf-spine arch. Currently, You have a different set of subnets under your Controller and ComputeHCI role. Taking internal_api reference from your baremetal_deployment.yaml ~~~ - network: internal_api subnet: internal_api_subnet01 >>> . . - network: internal_api subnet: internal_api_subnet02 >>>> ~~~ If leaf-spine arch is not what you want, Could you please change subnets names to be the same for your Controller and ComputeHCI role say internal_api. Also, I am assuming you are following documentation [2], For "openstack overcloud network provision" command also make sure your networks/subnets names in network_data.yaml (sample ref[3]) are consistent with what you as wish to do in baremetal_deployment.yaml [1] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml [2] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/network_v2.html#provision-baremetal-instances [3] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml On Tue, Aug 24, 2021 at 5:20 PM wodel youchi wrote: > Hi again, > > Here is the error I am getting when trying to generate the *overcloud-baremetal-deployed.yaml > *file : > CMD : openstack overcloud node provision --stack overcloud > --network-config --output ~/templates/overcloud-baremetal-deployed.yaml > ~/templates/baremetal_deployment.yaml > > Error : > >> >> >> >> >> >> >> >> >> >> >> *The full traceback is: >> >> File >> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >> line 601, in run_module >> File >> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >> line 494, in manage_instances_ports File >> "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run >> result = self.fn(*self.args, **self.kwargs) File >> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >> line 385, in _provision_ports File >> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >> line 319, in generate_port_defs* >> ], >> "template": >> "/home/stack/templates/nic-configs/bonds_vlans.j2" >> }, >> "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" >> }, >> { >> >> [215/1899] >> "network": "tenant", >> "subnet": "tenant_subnet01" >> }, >> { >> "network": "ctlplane", >> "vif": true >> } >> ], >> "nics": [ >> { >> "network": "ctlplane" >> } >> ], >> "ssh_public_keys": "ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAAAgQDdFv9qwUs3x6egY5Xke3gh2O8CnXTJ2h2jRpWYEFzL1fyZrMKykMBUEfbkQGYzONsE29/BpS265Df4RgZB3eHx4KWcaskSwjl >> DaUzxP0ZsSl2MzxtDIqE3UTrsmivNGx0ungcTorOc96V9daqU/Vu2HU8J+YEA6+OjddPX1ngz/w== >> root at undercloud.umaitek.dz ", >> "user_name": "heat-admin" >> }, >> { >> "capabilities": { >> "profile": "computeHCI" >> }, >> "config_drive": { >> "meta_data": { >> "instance-type": "ComputeHCI" >> } >> }, >> "hostname": "computehci-0", >> "image": { >> "href": >> "file:///var/lib/ironic/images/overcloud-full.raw", >> "kernel": >> "file:///var/lib/ironic/images/overcloud-full.vmlinuz", >> "ramdisk": >> "file:///var/lib/ironic/images/overcloud-full.initrd" >> }, >> "network_config": { >> "template": >> "/home/stack/templates/nic-configs/bonds_vlans.j2" >> }, >> "networks": [ >> "network": "internal_api", >> "subnet": "internal_api_subnet02" >> }, >> { >> "network": "tenant", >> "subnet": "tenant_subnet02" >> }, >> { >> "network": "storage", >> "subnet": "storage_subnet02" >> }, >> { >> "network": "storage_mgmt", >> "subnet": "storage_mgmt_subnet02" >> 2021-08-24 10:21:18.492374 | >> 52540075-9baf-0191-8598-000000000019 | FATAL | Provision instance >> network ports | localhost | error={ >> "changed": true, >> "error": "'internal_api_subnet02'", >> "invocation": { >> "module_args": { >> "api_timeout": null, >> "auth": null, >> "auth_type": null, >> "availability_zone": null, >> "ca_cert": null, >> "client_cert": null, >> "client_key": null, >> "concurrency": 2, >> "hostname_role_map": { >> "computehci-0": "ComputeHCI", >> "controller-0": "Controller" >> }, >> ... >> ... >> ... >> "provisioned_instances": [ >> >> [38/1899] >> { >> "hostname": "controller-0", >> "id": "1dff400f-0dd1-4eb0-b4c1-84397d387a4a", >> "name": "controller0" >> }, >> { >> "hostname": "computehci-0", >> "id": "3d6c399f-53b7-472b-b784-67193a485e43", >> "name": "computeHCI0" >> } >> ], >> "region_name": null, >> "stack_name": "overcloud", >> "state": "present", >> "timeout": 180, >> "validate_certs": null, >> "wait": true >> } >> >> >> >> >> * }, "msg": "Error managing network ports 'internal_api_subnet02'", >> "node_port_map": {}, "success": false}* >> 2021-08-24 10:21:18.494473 | 52540075-9baf-0191-8598-000000000019 | >> TIMING | Provision instance network ports | localhost | 0:04:58.315416 | >> 3.72s >> >> NO MORE HOSTS LEFT >> ************************************************************* >> >> PLAY RECAP >> ********************************************************************* >> localhost : ok=10 changed=3 unreachable=0 >> failed=1 skipped=5 rescued=0 ignored=0 >> 2021-08-24 10:21:18.498948 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary >> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.499338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >> Tasks: 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.499755 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: >> 0:04:58.320717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.500105 | UUID | >> Info | Host | Task Name | Run Time >> 2021-08-24 10:21:18.500449 | 52540075-9baf-0191-8598-000000000017 | >> SUMMARY | localhost | Provision instances | 285.25s >> 2021-08-24 10:21:18.500868 | 52540075-9baf-0191-8598-000000000014 | >> SUMMARY | localhost | Reserve instances | 6.08s >> 2021-08-24 10:21:18.501228 | 52540075-9baf-0191-8598-000000000019 | >> SUMMARY | localhost | Provision instance network ports | 3.72s >> 2021-08-24 10:21:18.501588 | 52540075-9baf-0191-8598-000000000013 | >> SUMMARY | localhost | Find existing instances | 1.52s >> 2021-08-24 10:21:18.501944 | 52540075-9baf-0191-8598-000000000012 | >> SUMMARY | localhost | Expand roles | 0.92s >> 2021-08-24 10:21:18.502281 | 52540075-9baf-0191-8598-00000000000c | >> SUMMARY | localhost | stat overcloud-full.raw | 0.26s >> 2021-08-24 10:21:18.502706 | 52540075-9baf-0191-8598-00000000000d | >> SUMMARY | localhost | stat overcloud-full.initrd | 0.19s >> 2021-08-24 10:21:18.503053 | 52540075-9baf-0191-8598-00000000000e | >> SUMMARY | localhost | Set file based default image | 0.04s >> 2021-08-24 10:21:18.503419 | 52540075-9baf-0191-8598-000000000018 | >> SUMMARY | localhost | Metalsmith log for provision instances | 0.04s >> 2021-08-24 10:21:18.503806 | 52540075-9baf-0191-8598-000000000016 | >> SUMMARY | localhost | Set concurrency fact | 0.04s >> 2021-08-24 10:21:18.504139 | 52540075-9baf-0191-8598-000000000015 | >> SUMMARY | localhost | Metalsmith log for reserve instances | 0.04s >> 2021-08-24 10:21:18.504469 | 52540075-9baf-0191-8598-00000000000f | >> SUMMARY | localhost | Set whole-disk file based default image | 0.03s >> 2021-08-24 10:21:18.504849 | 52540075-9baf-0191-8598-000000000010 | >> SUMMARY | localhost | Set glance based default image | 0.03s >> 2021-08-24 10:21:18.505246 | 52540075-9baf-0191-8598-000000000009 | >> SUMMARY | localhost | fail | 0.03s >> 2021-08-24 10:21:18.505627 | 52540075-9baf-0191-8598-000000000008 | >> SUMMARY | localhost | fail | 0.03s >> 2021-08-24 10:21:18.505987 | 52540075-9baf-0191-8598-00000000000a | >> SUMMARY | localhost | fail | 0.02s >> 2021-08-24 10:21:18.506315 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End Summary >> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.506693 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State >> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.507032 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did >> not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >> 2021-08-24 10:21:18.507351 | The following node(s) had failures: >> localhost >> 2021-08-24 10:21:18.507720 | >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Temporary directory [ /tmp/tripleob9lxg9vi ] cleaned up >> Ansible execution failed. playbook: >> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >> Status: failed, Return Code: 2 >> Temporary directory [ /tmp/tripleoyso22wsn ] cleaned up >> Exception occured while running the command >> Traceback (most recent call last): >> File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line >> 34, in run >> super(Command, self).run(parsed_args) >> File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", >> line 39, in run >> return super(Command, self).run(parsed_args) >> File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, in >> run >> return_code = self.take_action(parsed_args) or 0 >> File >> "/usr/lib/python3.6/site-packages/tripleoclient/v2/overcloud_node.py", line >> 323, in take_action >> extra_vars=extra_vars, >> File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line >> 724, in run_ansible_playbook >> raise RuntimeError(err_msg) >> RuntimeError: Ansible execution failed. playbook: >> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >> Status: failed, Return Code: 2 >> Ansible execution failed. playbook: >> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >> Status: failed, Return Code: 2 >> clean_up ProvisionNode: Ansible execution failed. playbook: >> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >> Status: failed, Return Code: 2 >> END return value: 1 >> > > Here is my baremetal_deployment.yaml file : > >> - name: Controller >> count: 1 >> hostname_format: controller-%index% >> 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: /home/stack/templates/nic-configs/bonds_vlans.j2 >> default_route_network: >> - external >> - name: ComputeHCI >> count: 1 >> hostname_format: computehci-%index% >> defaults: >> profile: computeHCI >> networks: >> - network: internal_api >> subnet: internal_api_subnet02 >> - network: tenant >> subnet: tenant_subnet02 >> - network: storage >> subnet: storage_subnet02 >> - network: storage_mgmt >> subnet: storage_mgmt_subnet02 >> network_config: >> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >> > > > If someone can help me and point me where to look. > Any help will be appreciated. > > Regards. > > Le lun. 23 août 2021 à 12:48, wodel youchi a > écrit : > >> 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 Tue Aug 24 14:32:39 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 24 Aug 2021 16:32:39 +0200 Subject: What is this error, does it effect the install? In-Reply-To: <01de01d798f3$8b7403b0$a25c0b10$@163.com> References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> Message-ID: On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > # kolla-ansible -i ./multinode prechecks > > > > > > PLAY RECAP *************************************************************************************************************** > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > The error is : > > > > The full traceback is: > > Traceback (most recent call last): > > File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py", line 102, in > > _ansiballz_main() > > File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py", line 94, in _ansiballz_main > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > File "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True) > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > return _run_module_code(code, init_globals, run_name, mod_spec) > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > mod_name, mod_spec, pkg_name, script_name) > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > exec(code, run_globals) > > File "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py", line 18, in > > ModuleNotFoundError: No module named 'docker' > > fatal: [localhost]: FAILED! => { > > "changed": false, > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > "module_stdout": "", > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > "rc": 1 > > } > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > What is it ? And does it effect the install ? > > It's a minor bug in that the tooling should not be trying to check docker on localhost. It should be fine to progress ignoring this particular issue. -yoctozepto From sz_cuitao at 163.com Tue Aug 24 14:34:44 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Tue, 24 Aug 2021 22:34:44 +0800 Subject: What is this error, does it effect the install? In-Reply-To: References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> Message-ID: <020801d798f5$30268800$90739800$@163.com> OK, thank you! -----Original Message----- From: Radosław Piliszek Sent: Tuesday, August 24, 2021 10:33 PM To: Tommy Sway Cc: openstack-discuss Subject: Re: What is this error, does it effect the install? On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > # kolla-ansible -i ./multinode prechecks > > > > > > PLAY RECAP > ********************************************************************** > ***************************************** > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > The error is : > > > > The full traceback is: > > Traceback (most recent call last): > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 102, in > > _ansiballz_main() > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 94, in _ansiballz_main > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > init_globals=None, run_name='__main__', alter_sys=True) > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > return _run_module_code(code, init_globals, run_name, mod_spec) > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > mod_name, mod_spec, pkg_name, script_name) > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > exec(code, run_globals) > > File > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_con > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > line 18, in > > ModuleNotFoundError: No module named 'docker' > > fatal: [localhost]: FAILED! => { > > "changed": false, > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > "module_stdout": "", > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > "rc": 1 > > } > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > What is it ? And does it effect the install ? > > It's a minor bug in that the tooling should not be trying to check docker on localhost. It should be fine to progress ignoring this particular issue. -yoctozepto From sandeepggn93 at gmail.com Tue Aug 24 14:28:28 2021 From: sandeepggn93 at gmail.com (Sandeep Yadav) Date: Tue, 24 Aug 2021 19:58:28 +0530 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: >> Could you please change subnets names to be the same for your Controller and ComputeHCI role say internal_api. typo: Could you please change subnets names to be the same for your Controller and ComputeHCI role say internal_api_subnet. On Tue, Aug 24, 2021 at 7:48 PM Sandeep Yadav wrote: > Hello, > > To me it looks like the example shared in the documentation[1] is for > leaf-spine arch. > > Currently, You have a different set of subnets under your Controller and > ComputeHCI role. > > Taking internal_api reference from your baremetal_deployment.yaml > ~~~ > - network: internal_api > subnet: internal_api_subnet01 >>> > . > . > - network: internal_api > subnet: internal_api_subnet02 >>>> > ~~~ > > If leaf-spine arch is not what you want, Could you please change subnets > names to be the same for your Controller and ComputeHCI role say > internal_api. > > Also, I am assuming you are following documentation [2], For "openstack > overcloud network provision" command also make sure your networks/subnets > names in network_data.yaml (sample ref[3]) are consistent with what you as > wish to do in baremetal_deployment.yaml > > [1] > https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml > [2] > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/network_v2.html#provision-baremetal-instances > [3] > https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml > > On Tue, Aug 24, 2021 at 5:20 PM wodel youchi > wrote: > >> Hi again, >> >> Here is the error I am getting when trying to generate the *overcloud-baremetal-deployed.yaml >> *file : >> CMD : openstack overcloud node provision --stack overcloud >> --network-config --output ~/templates/overcloud-baremetal-deployed.yaml >> ~/templates/baremetal_deployment.yaml >> >> Error : >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *The full traceback is: >>> >>> File >>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>> line 601, in run_module >>> File >>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>> line 494, in manage_instances_ports File >>> "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run >>> result = self.fn(*self.args, **self.kwargs) File >>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>> line 385, in _provision_ports File >>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>> line 319, in generate_port_defs* >>> ], >>> "template": >>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>> }, >>> "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" >>> }, >>> { >>> >>> [215/1899] >>> "network": "tenant", >>> "subnet": "tenant_subnet01" >>> }, >>> { >>> "network": "ctlplane", >>> "vif": true >>> } >>> ], >>> "nics": [ >>> { >>> "network": "ctlplane" >>> } >>> ], >>> "ssh_public_keys": "ssh-rsa >>> AAAAB3NzaC1yc2EAAAADAQABAAAAgQDdFv9qwUs3x6egY5Xke3gh2O8CnXTJ2h2jRpWYEFzL1fyZrMKykMBUEfbkQGYzONsE29/BpS265Df4RgZB3eHx4KWcaskSwjl >>> DaUzxP0ZsSl2MzxtDIqE3UTrsmivNGx0ungcTorOc96V9daqU/Vu2HU8J+YEA6+OjddPX1ngz/w== >>> root at undercloud.umaitek.dz ", >>> "user_name": "heat-admin" >>> }, >>> { >>> "capabilities": { >>> "profile": "computeHCI" >>> }, >>> "config_drive": { >>> "meta_data": { >>> "instance-type": "ComputeHCI" >>> } >>> }, >>> "hostname": "computehci-0", >>> "image": { >>> "href": >>> "file:///var/lib/ironic/images/overcloud-full.raw", >>> "kernel": >>> "file:///var/lib/ironic/images/overcloud-full.vmlinuz", >>> "ramdisk": >>> "file:///var/lib/ironic/images/overcloud-full.initrd" >>> }, >>> "network_config": { >>> "template": >>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>> }, >>> "networks": [ >>> "network": "internal_api", >>> "subnet": "internal_api_subnet02" >>> }, >>> { >>> "network": "tenant", >>> "subnet": "tenant_subnet02" >>> }, >>> { >>> "network": "storage", >>> "subnet": "storage_subnet02" >>> }, >>> { >>> "network": "storage_mgmt", >>> "subnet": "storage_mgmt_subnet02" >>> 2021-08-24 10:21:18.492374 | >>> 52540075-9baf-0191-8598-000000000019 | FATAL | Provision instance >>> network ports | localhost | error={ >>> "changed": true, >>> "error": "'internal_api_subnet02'", >>> "invocation": { >>> "module_args": { >>> "api_timeout": null, >>> "auth": null, >>> "auth_type": null, >>> "availability_zone": null, >>> "ca_cert": null, >>> "client_cert": null, >>> "client_key": null, >>> "concurrency": 2, >>> "hostname_role_map": { >>> "computehci-0": "ComputeHCI", >>> "controller-0": "Controller" >>> }, >>> ... >>> ... >>> ... >>> "provisioned_instances": [ >>> >>> [38/1899] >>> { >>> "hostname": "controller-0", >>> "id": "1dff400f-0dd1-4eb0-b4c1-84397d387a4a", >>> "name": "controller0" >>> }, >>> { >>> "hostname": "computehci-0", >>> "id": "3d6c399f-53b7-472b-b784-67193a485e43", >>> "name": "computeHCI0" >>> } >>> ], >>> "region_name": null, >>> "stack_name": "overcloud", >>> "state": "present", >>> "timeout": 180, >>> "validate_certs": null, >>> "wait": true >>> } >>> >>> >>> >>> >>> * }, "msg": "Error managing network ports 'internal_api_subnet02'", >>> "node_port_map": {}, "success": false}* >>> 2021-08-24 10:21:18.494473 | 52540075-9baf-0191-8598-000000000019 | >>> TIMING | Provision instance network ports | localhost | 0:04:58.315416 | >>> 3.72s >>> >>> NO MORE HOSTS LEFT >>> ************************************************************* >>> >>> PLAY RECAP >>> ********************************************************************* >>> localhost : ok=10 changed=3 unreachable=0 >>> failed=1 skipped=5 rescued=0 ignored=0 >>> 2021-08-24 10:21:18.498948 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary >>> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.499338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >>> Tasks: 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.499755 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: >>> 0:04:58.320717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.500105 | UUID | >>> Info | Host | Task Name | Run Time >>> 2021-08-24 10:21:18.500449 | 52540075-9baf-0191-8598-000000000017 | >>> SUMMARY | localhost | Provision instances | 285.25s >>> 2021-08-24 10:21:18.500868 | 52540075-9baf-0191-8598-000000000014 | >>> SUMMARY | localhost | Reserve instances | 6.08s >>> 2021-08-24 10:21:18.501228 | 52540075-9baf-0191-8598-000000000019 | >>> SUMMARY | localhost | Provision instance network ports | 3.72s >>> 2021-08-24 10:21:18.501588 | 52540075-9baf-0191-8598-000000000013 | >>> SUMMARY | localhost | Find existing instances | 1.52s >>> 2021-08-24 10:21:18.501944 | 52540075-9baf-0191-8598-000000000012 | >>> SUMMARY | localhost | Expand roles | 0.92s >>> 2021-08-24 10:21:18.502281 | 52540075-9baf-0191-8598-00000000000c | >>> SUMMARY | localhost | stat overcloud-full.raw | 0.26s >>> 2021-08-24 10:21:18.502706 | 52540075-9baf-0191-8598-00000000000d | >>> SUMMARY | localhost | stat overcloud-full.initrd | 0.19s >>> 2021-08-24 10:21:18.503053 | 52540075-9baf-0191-8598-00000000000e | >>> SUMMARY | localhost | Set file based default image | 0.04s >>> 2021-08-24 10:21:18.503419 | 52540075-9baf-0191-8598-000000000018 | >>> SUMMARY | localhost | Metalsmith log for provision instances | 0.04s >>> 2021-08-24 10:21:18.503806 | 52540075-9baf-0191-8598-000000000016 | >>> SUMMARY | localhost | Set concurrency fact | 0.04s >>> 2021-08-24 10:21:18.504139 | 52540075-9baf-0191-8598-000000000015 | >>> SUMMARY | localhost | Metalsmith log for reserve instances | 0.04s >>> 2021-08-24 10:21:18.504469 | 52540075-9baf-0191-8598-00000000000f | >>> SUMMARY | localhost | Set whole-disk file based default image | 0.03s >>> 2021-08-24 10:21:18.504849 | 52540075-9baf-0191-8598-000000000010 | >>> SUMMARY | localhost | Set glance based default image | 0.03s >>> 2021-08-24 10:21:18.505246 | 52540075-9baf-0191-8598-000000000009 | >>> SUMMARY | localhost | fail | 0.03s >>> 2021-08-24 10:21:18.505627 | 52540075-9baf-0191-8598-000000000008 | >>> SUMMARY | localhost | fail | 0.03s >>> 2021-08-24 10:21:18.505987 | 52540075-9baf-0191-8598-00000000000a | >>> SUMMARY | localhost | fail | 0.02s >>> 2021-08-24 10:21:18.506315 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.506693 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State >>> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.507032 | ~~~~~~~~~~~~~~~~~~ Number of nodes which >>> did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >>> 2021-08-24 10:21:18.507351 | The following node(s) had failures: >>> localhost >>> 2021-08-24 10:21:18.507720 | >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Temporary directory [ /tmp/tripleob9lxg9vi ] cleaned up >>> Ansible execution failed. playbook: >>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>> Status: failed, Return Code: 2 >>> Temporary directory [ /tmp/tripleoyso22wsn ] cleaned up >>> Exception occured while running the command >>> Traceback (most recent call last): >>> File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line >>> 34, in run >>> super(Command, self).run(parsed_args) >>> File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", >>> line 39, in run >>> return super(Command, self).run(parsed_args) >>> File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, in >>> run >>> return_code = self.take_action(parsed_args) or 0 >>> File >>> "/usr/lib/python3.6/site-packages/tripleoclient/v2/overcloud_node.py", line >>> 323, in take_action >>> extra_vars=extra_vars, >>> File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line >>> 724, in run_ansible_playbook >>> raise RuntimeError(err_msg) >>> RuntimeError: Ansible execution failed. playbook: >>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>> Status: failed, Return Code: 2 >>> Ansible execution failed. playbook: >>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>> Status: failed, Return Code: 2 >>> clean_up ProvisionNode: Ansible execution failed. playbook: >>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>> Status: failed, Return Code: 2 >>> END return value: 1 >>> >> >> Here is my baremetal_deployment.yaml file : >> >>> - name: Controller >>> count: 1 >>> hostname_format: controller-%index% >>> 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: /home/stack/templates/nic-configs/bonds_vlans.j2 >>> default_route_network: >>> - external >>> - name: ComputeHCI >>> count: 1 >>> hostname_format: computehci-%index% >>> defaults: >>> profile: computeHCI >>> networks: >>> - network: internal_api >>> subnet: internal_api_subnet02 >>> - network: tenant >>> subnet: tenant_subnet02 >>> - network: storage >>> subnet: storage_subnet02 >>> - network: storage_mgmt >>> subnet: storage_mgmt_subnet02 >>> network_config: >>> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >>> >> >> >> If someone can help me and point me where to look. >> Any help will be appreciated. >> >> Regards. >> >> Le lun. 23 août 2021 à 12:48, wodel youchi a >> écrit : >> >>> 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 dvd at redhat.com Tue Aug 24 15:02:25 2021 From: dvd at redhat.com (David Vallee Delisle) Date: Tue, 24 Aug 2021 11:02:25 -0400 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 DVD On Tue, Aug 24, 2021 at 10:22 AM Marios Andreou wrote: > great news thanks Slagle > > On Tuesday, August 24, 2021, James Slagle wrote: > >> I'm submitting my candidacy for TripleO PTL. >> >> I look forward to the opportunity to help the community as we tackle some >> of our upcoming challenges — the transition to CentOS/RHEL 9, increasing >> complexity around container management, and revisiting our commitments to >> our adopted tooling. >> >> I'd suggest that to assist with these efforts, we focus on our review >> prioritization and in progress work streams. I would like to see folks >> representing review priorities during the TripleO meeting and on an >> etherpad. I'd also like to see less parallel streams of work, with the >> opportunity for more folks to collaborate on common priorities. >> >> If elected as PTL, I would plan to organize the efforts around such an >> approach. >> >> Thank you for the consideration. >> >> https://review.opendev.org/c/openstack/election/+/805840 >> >> -- >> -- James Slagle >> -- >> > > > -- > _sent from my mobile - sorry for spacing spelling etc_ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Tue Aug 24 15:32:35 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 24 Aug 2021 17:32:35 +0200 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: References: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> Message-ID: Anycase, after an image update instances are down but also restarting them, the system becomes very slow. I do not know if because I am not really uploading the openstack images but only retagging them to simulate an update. The following are my steps: - change images tag on local registry - apply the new tag in globals.yml - pull the images with new tag on computes and controllers. - run deploy Any suggestion, please? Ignazio Il Mar 24 Ago 2021, 13:47 Ignazio Cassano ha scritto: > Hello Sean, > I do not know what is "systemd-machined". > My compute nodes are ubuntu 20.40, while images are centos source wallaby. > Reading the logs is sure that nova compute lost connection with libvirtd, > but in a installation where containers are not used (no kolla) this does > not happen. > What I must check, please ? > Is the above bug considered still opened ? > Ignazio > > Il giorno mar 24 ago 2021 alle ore 13:35 Sean Mooney > ha scritto: > >> On Tue, 2021-08-24 at 13:00 +0200, Ignazio Cassano wrote: >> > I tried again. I started with e new installation of wallaby but this >> time I >> > used centos source instead of ubuntu source. >> > After first deploy I stared a virtual machine. >> > Then I update the images and I ran a new deploy. >> > Instance went down and in the nova compute log I got the following: >> > https://paste.openstack.org/show/808282/ >> >> i dont know if its the same issue but you might be hitting this >> https://bugzilla.redhat.com/show_bug.cgi?id=1963164 >> tl;dr is systemd-machined previously did not work inside the contaiener >> so livert fell >> back to its generic cgroups backend, ignoring machined managing mancines >> without it but recently systemd-machined started >> working in the contianer. when you upgrade libvirt switches to its >> machined backend but it does not have the vms registred in that >> so it stopps them. >> >> >> > >> > Ignazio >> > >> > >> > Il giorno mar 24 ago 2021 alle ore 09:02 Ignazio Cassano < >> > ignaziocassano at gmail.com> ha scritto: >> > >> > > Hello, about the above issue, we discussed on yesterday on >> openstack-kolla >> > > IRC. >> > > The issue is not related to masakary, but it happens when >> nova-compute is >> > > redeployed with the following error in >> > > linvirt.log: >> > > 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, >> > > package: 0ubuntu8.12 (Christian Ehrhardt < >> christian.ehrhardt at canonical.com> >> > > Tue, 20 Jul 2021 14:13:56 +0200) >> > > 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 >> > > 2021-08-24 06:59:25.012+0000: 3224764: error : >> > > dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary >> > > /usr/sbin/dnsmasq: No such file or directory >> > > 2021-08-24 06:59:25.857+0000: 3224822: error : >> qemuMonitorOpenUnix:292 : >> > > failed to connect to monitor socket: Connection refused >> > > 2021-08-24 06:59:25.876+0000: 3224821: error : >> qemuMonitorOpenUnix:292 : >> > > failed to connect to monitor socket: Connection refused >> > > 2021-08-24 06:59:44.670+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-alpha' on this host >> > > 2021-08-24 06:59:44.673+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-arm' on this host >> > > 2021-08-24 06:59:44.674+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-arm' on this host >> > > 2021-08-24 06:59:44.677+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-arm' on this host >> > > 2021-08-24 06:59:44.681+0000: 3224749: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-aarch64' on this host >> > > 2021-08-24 06:59:44.684+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-cris' on this host >> > > 2021-08-24 06:59:44.713+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-lm32' on this host >> > > 2021-08-24 06:59:44.716+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-m68k' on this host >> > > 2021-08-24 06:59:44.719+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-microblaze' on this host >> > > 2021-08-24 06:59:44.721+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-microblazeel' on this host >> > > 2021-08-24 06:59:44.725+0000: 3224749: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-mips' on this host >> > > 2021-08-24 06:59:44.727+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-mipsel' on this host >> > > 2021-08-24 06:59:44.731+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-mips64' on this host >> > > 2021-08-24 06:59:44.733+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-mips64el' on this host >> > > 2021-08-24 06:59:44.736+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc' on this host >> > > 2021-08-24 06:59:44.739+0000: 3224749: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64' on this host >> > > 2021-08-24 06:59:44.741+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64' on this host >> > > 2021-08-24 06:59:44.744+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64' on this host >> > > 2021-08-24 06:59:44.747+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64le' on this host >> > > 2021-08-24 06:59:44.750+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64le' on this host >> > > 2021-08-24 06:59:44.753+0000: 3224749: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-ppc64le' on this host >> > > 2021-08-24 06:59:44.755+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-riscv32' on this host >> > > 2021-08-24 06:59:44.758+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-riscv64' on this host >> > > 2021-08-24 06:59:44.761+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-s390x' on this host >> > > 2021-08-24 06:59:44.763+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-sh4' on this host >> > > 2021-08-24 06:59:44.766+0000: 3224749: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-sh4eb' on this host >> > > 2021-08-24 06:59:44.768+0000: 3224751: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-sparc' on this host >> > > 2021-08-24 06:59:44.771+0000: 3224753: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-sparc64' on this host >> > > 2021-08-24 06:59:44.773+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-unicore32' on this host >> > > 2021-08-24 06:59:44.795+0000: 3224750: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-xtensa' on this host >> > > 2021-08-24 06:59:44.798+0000: 3224752: error : >> > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not >> supported >> > > by '/usr/bin/qemu-system-xtensaeb' on this host >> > > >> > > Ignazio >> > > >> > > Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < >> > > ignaziocassano at gmail.com> ha scritto: >> > > >> > > > Hello All, >> > > > I am new in kolla so probably my procedure is not correct. >> > > > Last week I installed wallaby and I deployed on my openstack only >> two >> > > > virtual machines. >> > > > Today I tried to updated images so: >> > > > >> > > > 1 pulled new images on my local registry >> > > > 2 pushed new images on my local registry >> > > > 3 pushed new images from my local registry to controllers and >> compute >> > > > nodes >> > > > (kolla-ansible pull --limit control,compute >> > > > 4 run kolla-ansible deploy >> > > > >> > > > All virtual machines went in shutoff state. >> > > > What is wrong in my procedure ? >> > > > >> > > > Regards >> > > > Ignazio >> > > > >> > > >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Tue Aug 24 15:34:04 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 24 Aug 2021 11:34:04 -0400 Subject: [election][cinder] PTL Candidacy for Yoga Message-ID: Hello everyone, I'd like to announce my candidacy for Cinder PTL for the Yoga cycle. The primary challenge we face in the Cinder community continues to be that our reviewing bandwidth has declined at the same time third-party driver contributions have not decreased. As I see it, the problem is that many vendors who maintain third-party drivers do not appear to be clear on the concept of community participation. (For what it's worth, I think this is more a manager problem than a developer problem, but the effect on Cinder is the same, namely, lots of request for reviews and not much doing of reviews. The Cinder documentation has information about how to review, how you don't need to be a core to do valuable reviews, etc., but it's not clear that many people have actually read them.) The Cinder community has tried to address this participation deficit in Xena by providing more upstream activities for contributors (for example, the monthly Festival of XS reviews [0] and the weekly Bug Squad meetings [1]), and these have had decent participation. In Yoga, I'd like to explore having some kind of Review Squad meeting to give people a chance to get "live" feedback on features under development. Some people do use the weekly Cinder meeting for this, but not everyone takes advantage of that, plus weekly meeting time is limited. I hate to propose yet another team meeting, but on the other hand, the bug squad and festival of reviews meetings are extremely productive, so I don't mind proposing another *productive* meeting. (We'll simply cancel it if it turns out that people don't take advantage. Also, I'm open to other ideas ... the key issue is providing faster feedback and more visibility for people developing cinder features, and allowing cinder cores to use their review time productively. So two key issues.) On the positive side, we did add a new cinder core during Xena and there's another person right on the verge of being proposed as a core. So that will help address review bandwidth, though I want to stress that non-core reviews are extremely important to the project as well. Our core reviewers also develop features and fix bugs--they are not full-time code reviewers. And the way to become a cinder core is to review widely in the project and demonstrate a good breadth of knowledge of the software. (As always, anyone currently working on cinder project who's interested becoming a cinder core, please contact me (or any of the current cores) to discuss what the expectations are.) Also on the good side is that we've done quite a bit of work on the Cinder CI this cycle. (I'm not going to tempt fate by saying anything more about that.) With respect to the details of Cinder development in Yoga, I expect those to emerge from our virtual PTG discussions in October. You can help set the agenda here: https://etherpad.opendev.org/p/yoga-ptg-cinder-planning To summarize, I would like to continue working on improving the review throughput of the Cinder team and find additional ways to get people more thoroughly involved in the project. Thanks for reading this far, and thank you for your consideration. Brian Rosmaita (rosmaita) [0] http://eavesdrop.openstack.org/#Cinder_Festival_of_XS_Reviews [1] http://eavesdrop.openstack.org/#Cinder_Bug_Squad_Meeting From elod.illes at est.tech Tue Aug 24 16:02:53 2021 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Tue, 24 Aug 2021 18:02:53 +0200 Subject: [election][Release_Management] PTL candidacy for Yoga Message-ID: Hello OpenStack Community, I would like to announce my candidacy for PTL of the Release Management team for the Yoga cycle. I became core member in the Release Management team during Wallaby cycle to help the work of the team with release patch reviews, but I was involved in the release process for some time already as my focus has been Stable Maintenance (especially around the introduction of the Extended Maintenance process) as being member of the stable-maint-core group. Thanks to the great work of the former PTLs and team members of the Release Management team, now the process is fairly automated and should be straightforward to follow. During the Yoga cycle I'm planning to get familiar with all the aspects of the release management (with the help of the more experienced team members) and continue the work that my predecessors started and keep things maintained. Thanks for your consideration, Előd Illés (elodilles) From sandeepggn93 at gmail.com Tue Aug 24 16:16:45 2021 From: sandeepggn93 at gmail.com (Sandeep Yadav) Date: Tue, 24 Aug 2021 21:46:45 +0530 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 On Tue, 24 Aug, 2021, 8:41 PM David Vallee Delisle, wrote: > +2 > > DVD > > > On Tue, Aug 24, 2021 at 10:22 AM Marios Andreou wrote: > >> great news thanks Slagle >> >> On Tuesday, August 24, 2021, James Slagle wrote: >> >>> I'm submitting my candidacy for TripleO PTL. >>> >>> I look forward to the opportunity to help the community as we tackle >>> some of our upcoming challenges — the transition to CentOS/RHEL 9, >>> increasing complexity around container management, and revisiting our >>> commitments to our adopted tooling. >>> >>> I'd suggest that to assist with these efforts, we focus on our review >>> prioritization and in progress work streams. I would like to see folks >>> representing review priorities during the TripleO meeting and on an >>> etherpad. I'd also like to see less parallel streams of work, with the >>> opportunity for more folks to collaborate on common priorities. >>> >>> If elected as PTL, I would plan to organize the efforts around such an >>> approach. >>> >>> Thank you for the consideration. >>> >>> https://review.opendev.org/c/openstack/election/+/805840 >>> >>> -- >>> -- James Slagle >>> -- >>> >> >> >> -- >> _sent from my mobile - sorry for spacing spelling etc_ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beagles at redhat.com Tue Aug 24 16:55:48 2021 From: beagles at redhat.com (Brent Eagles) Date: Tue, 24 Aug 2021 14:25:48 -0230 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: On Tue, Aug 24, 2021 at 08:13:46AM -0400, James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- +2 from me. Thanks James! -- Brent Eagles Principal Software Engineer Red Hat Inc. From sz_cuitao at 163.com Tue Aug 24 17:24:17 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Wed, 25 Aug 2021 01:24:17 +0800 Subject: What is this error, does it effect the install? In-Reply-To: References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> Message-ID: <021f01d7990c$de474930$9ad5db90$@163.com> Could you please tell me again that when kolla tool is used for formal deployment, if there are failed steps or nodes are damaged in the middle, is it ok for me to reinstall a new node, add it in and run the deployment command again? I've heard that Ansible-based deployments are generally idempotent, so that shouldn't be a problem. Isn't it? Thank you very much! -----Original Message----- From: Radosław Piliszek Sent: Tuesday, August 24, 2021 10:33 PM To: Tommy Sway Cc: openstack-discuss Subject: Re: What is this error, does it effect the install? On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > # kolla-ansible -i ./multinode prechecks > > > > > > PLAY RECAP > ********************************************************************** > ***************************************** > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > The error is : > > > > The full traceback is: > > Traceback (most recent call last): > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 102, in > > _ansiballz_main() > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 94, in _ansiballz_main > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > File > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > init_globals=None, run_name='__main__', alter_sys=True) > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > return _run_module_code(code, init_globals, run_name, mod_spec) > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > mod_name, mod_spec, pkg_name, script_name) > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > exec(code, run_globals) > > File > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_con > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > line 18, in > > ModuleNotFoundError: No module named 'docker' > > fatal: [localhost]: FAILED! => { > > "changed": false, > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > "module_stdout": "", > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > "rc": 1 > > } > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > What is it ? And does it effect the install ? > > It's a minor bug in that the tooling should not be trying to check docker on localhost. It should be fine to progress ignoring this particular issue. -yoctozepto From wodel.youchi at gmail.com Tue Aug 24 17:07:17 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 24 Aug 2021 18:07:17 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: Hi and thanks for the help. My network is simple, I have 5 nics per node : - first nic : provisioning - second and third nics as bond : storage and storage mgmt - fourth and fifth nics as bond : tenant, api and external I modified the baremetal_deployment.yaml as you suggested, > - name: Controller > count: 3 > hostname_format: controller-%index% > defaults: > profile: control > networks: > - network: external > subnet: external_subnet > - network: internal_api > subnet: internal_api_subnet > - network: storage > subnet: storage_subnet > - network: storage_mgmt > subnet: storage_mgmt_subnet > - network: tenant > subnet: tenant_subnet > network_config: > template: /home/stack/templates/nic-configs/bonds_vlans.j2 > default_route_network: > - external > - name: ComputeHCI > count: 3 > hostname_format: computehci-%index% > defaults: > profile: computeHCI > networks: > - network: internal_api > subnet: internal_api_subnet > - network: tenant > subnet: tenant_subnet > - network: storage > subnet: storage_subnet > - network: storage_mgmt > subnet: storage_mgmt_subnet > network_config: > template: /home/stack/templates/nic-configs/bonds_vlans.j2 > but still errors, and this time I have nothing to go with Error : > <10.100.4.7> SSH: EXEC ssh -o UserKnownHostsFile=/dev/null -o > StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPersist=30m -o > ServerAliveInterval=64 -o ServerAliveCountMax=[55/1822] > ompression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no > -o ForwardAgent=yes -o PreferredAuthentications=publickey -T -o > StrictHostKeyChecking=no -o KbdInteractiveAuthentic > ation=no -o > PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey > -o PasswordAuthentication=no -o 'User="heat-admin"' -o ConnectTimeout=30 -o > ControlPath=/home/stack/.an > sible/cp/ca32d1049e 10.100.4.7 '/bin/sh -c '"'"'rm -f -r > /home/heat-admin/.ansible/tmp/ansible-tmp-1629824478.3189409-228106-213914436967091/ > > /dev/null 2>&1 && sleep 0'"'"'' > > > > > > > > > *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 | > FATAL | Render network_config from template | computehci-1 | error={ > "censored": "the output has been hidden due to the fact that 'no_log: true' > was specified for this result", "changed": false}2021-08-24 > 18:01:18.372773 | 52540075-9baf-8232-d4fa-0000000000a0 | TIMING | > tripleo_network_config : Render network_config from template | computehci-1 > | 0:00:45.837722 | 0.19s 2021-08-24 18:01:18.373749 | > 52540075-9baf-8232-d4fa-0000000000a0 | FATAL | Render network_config > from template | computehci-0 | error={ "censored": "the output has been > hidden due to the fact that 'no_log: true' was specified for this result", > "changed": false}* > 2021-08-24 18:01:18.374225 | 52540075-9baf-8232-d4fa-0000000000a0 | > TIMING | tripleo_network_config : Render network_config from template | > computehci-0 | 0:00:45.839181 | 0.20s > <10.100.4.13> rc=0, stdout and stderr censored due to no log > <10.100.4.10> rc=0, stdout and stderr censored due to no log > <10.100.4.23> rc=0, stdout and stderr censored due to no log > 2021-08-24 18:01:18.385393 | 52540075-9baf-8232-d4fa-0000000000a0 | > FATAL | Render network_config from template | controller-0 | error={ > "censored": "the output has been hidden due to the fact that 'no_log: > true' was specified for this result", > "changed": false > } > 2021-08-24 18:01:18.385962 | 52540075-9baf-8232-d4fa-0000000000a0 | > TIMING | tripleo_network_config : Render network_config from template | > controller-0 | 0:00:45.850915 | 0.19s > 2021-08-24 18:01:18.387075 | 52540075-9baf-8232-d4fa-0000000000a0 | > FATAL | Render network_config from template | controller-1 | error={ > > "censored": "the output has been hidden due to the fact that 'no_log: > true' was specified for this result", > > "changed": false > } > 2021-08-24 18:01:18.387597 | 52540075-9baf-8232-d4fa-0000000000a0 | > TIMING | tripleo_network_config : Render network_config from template | > controller-1 | 0:00:45.852553 | 0.18s > 2021-08-24 18:01:18.388389 | 52540075-9baf-8232-d4fa-0000000000a0 | > FATAL | Render network_config from template | computehci-2 | error={ > > "censored": "the output has been hidden due to the fact that 'no_log: > true' was specified for this result", > > "changed": false > } > 2021-08-24 18:01:18.388902 | 52540075-9baf-8232-d4fa-0000000000a0 | > TIMING | tripleo_network_config : Render network_config from template | > computehci-2 | 0:00:45.853857 | 0.20s > <10.100.4.7> rc=0, stdout and stderr censored due to no log > 2021-08-24 18:01:18.399921 | 52540075-9baf-8232-d4fa-0000000000a0 | > FATAL | Render network_config from template | controller-2 | error={ > "censored": "the output has been hidden due to the fact that 'no_log: > true' was specified for this result", > "changed": false > Any ideas? Le mar. 24 août 2021 à 15:28, Sandeep Yadav a écrit : > >> Could you please change subnets names to be the same for your > Controller and ComputeHCI role say internal_api. > > typo: Could you please change subnets names to be the same for your > Controller and ComputeHCI role say internal_api_subnet. > > > On Tue, Aug 24, 2021 at 7:48 PM Sandeep Yadav > wrote: > >> Hello, >> >> To me it looks like the example shared in the documentation[1] is for >> leaf-spine arch. >> >> Currently, You have a different set of subnets under your Controller and >> ComputeHCI role. >> >> Taking internal_api reference from your baremetal_deployment.yaml >> ~~~ >> - network: internal_api >> subnet: internal_api_subnet01 >>> >> . >> . >> - network: internal_api >> subnet: internal_api_subnet02 >>>> >> ~~~ >> >> If leaf-spine arch is not what you want, Could you please change subnets >> names to be the same for your Controller and ComputeHCI role say >> internal_api. >> >> Also, I am assuming you are following documentation [2], For "openstack >> overcloud network provision" command also make sure your networks/subnets >> names in network_data.yaml (sample ref[3]) are consistent with what you as >> wish to do in baremetal_deployment.yaml >> >> [1] >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml >> [2] >> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/network_v2.html#provision-baremetal-instances >> [3] >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml >> >> On Tue, Aug 24, 2021 at 5:20 PM wodel youchi >> wrote: >> >>> Hi again, >>> >>> Here is the error I am getting when trying to generate the *overcloud-baremetal-deployed.yaml >>> *file : >>> CMD : openstack overcloud node provision --stack overcloud >>> --network-config --output ~/templates/overcloud-baremetal-deployed.yaml >>> ~/templates/baremetal_deployment.yaml >>> >>> Error : >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *The full traceback is: >>>> >>>> File >>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>> line 601, in run_module >>>> File >>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>> line 494, in manage_instances_ports File >>>> "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run >>>> result = self.fn(*self.args, **self.kwargs) File >>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>> line 385, in _provision_ports File >>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>> line 319, in generate_port_defs* >>>> ], >>>> "template": >>>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>>> }, >>>> "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" >>>> }, >>>> { >>>> >>>> [215/1899] >>>> "network": "tenant", >>>> "subnet": "tenant_subnet01" >>>> }, >>>> { >>>> "network": "ctlplane", >>>> "vif": true >>>> } >>>> ], >>>> "nics": [ >>>> { >>>> "network": "ctlplane" >>>> } >>>> ], >>>> "ssh_public_keys": "ssh-rsa >>>> AAAAB3NzaC1yc2EAAAADAQABAAAAgQDdFv9qwUs3x6egY5Xke3gh2O8CnXTJ2h2jRpWYEFzL1fyZrMKykMBUEfbkQGYzONsE29/BpS265Df4RgZB3eHx4KWcaskSwjl >>>> DaUzxP0ZsSl2MzxtDIqE3UTrsmivNGx0ungcTorOc96V9daqU/Vu2HU8J+YEA6+OjddPX1ngz/w== >>>> root at undercloud.umaitek.dz ", >>>> "user_name": "heat-admin" >>>> }, >>>> { >>>> "capabilities": { >>>> "profile": "computeHCI" >>>> }, >>>> "config_drive": { >>>> "meta_data": { >>>> "instance-type": "ComputeHCI" >>>> } >>>> }, >>>> "hostname": "computehci-0", >>>> "image": { >>>> "href": >>>> "file:///var/lib/ironic/images/overcloud-full.raw", >>>> "kernel": >>>> "file:///var/lib/ironic/images/overcloud-full.vmlinuz", >>>> "ramdisk": >>>> "file:///var/lib/ironic/images/overcloud-full.initrd" >>>> }, >>>> "network_config": { >>>> "template": >>>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>>> }, >>>> "networks": [ >>>> "network": "internal_api", >>>> "subnet": "internal_api_subnet02" >>>> }, >>>> { >>>> "network": "tenant", >>>> "subnet": "tenant_subnet02" >>>> }, >>>> { >>>> "network": "storage", >>>> "subnet": "storage_subnet02" >>>> }, >>>> { >>>> "network": "storage_mgmt", >>>> "subnet": "storage_mgmt_subnet02" >>>> 2021-08-24 10:21:18.492374 | >>>> 52540075-9baf-0191-8598-000000000019 | FATAL | Provision instance >>>> network ports | localhost | error={ >>>> "changed": true, >>>> "error": "'internal_api_subnet02'", >>>> "invocation": { >>>> "module_args": { >>>> "api_timeout": null, >>>> "auth": null, >>>> "auth_type": null, >>>> "availability_zone": null, >>>> "ca_cert": null, >>>> "client_cert": null, >>>> "client_key": null, >>>> "concurrency": 2, >>>> "hostname_role_map": { >>>> "computehci-0": "ComputeHCI", >>>> "controller-0": "Controller" >>>> }, >>>> ... >>>> ... >>>> ... >>>> "provisioned_instances": [ >>>> >>>> [38/1899] >>>> { >>>> "hostname": "controller-0", >>>> "id": "1dff400f-0dd1-4eb0-b4c1-84397d387a4a", >>>> "name": "controller0" >>>> }, >>>> { >>>> "hostname": "computehci-0", >>>> "id": "3d6c399f-53b7-472b-b784-67193a485e43", >>>> "name": "computeHCI0" >>>> } >>>> ], >>>> "region_name": null, >>>> "stack_name": "overcloud", >>>> "state": "present", >>>> "timeout": 180, >>>> "validate_certs": null, >>>> "wait": true >>>> } >>>> >>>> >>>> >>>> >>>> * }, "msg": "Error managing network ports 'internal_api_subnet02'", >>>> "node_port_map": {}, "success": false}* >>>> 2021-08-24 10:21:18.494473 | 52540075-9baf-0191-8598-000000000019 | >>>> TIMING | Provision instance network ports | localhost | 0:04:58.315416 | >>>> 3.72s >>>> >>>> NO MORE HOSTS LEFT >>>> ************************************************************* >>>> >>>> PLAY RECAP >>>> ********************************************************************* >>>> localhost : ok=10 changed=3 unreachable=0 >>>> failed=1 skipped=5 rescued=0 ignored=0 >>>> 2021-08-24 10:21:18.498948 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary >>>> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.499338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >>>> Tasks: 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.499755 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed >>>> Time: 0:04:58.320717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.500105 | UUID | >>>> Info | Host | Task Name | Run Time >>>> 2021-08-24 10:21:18.500449 | 52540075-9baf-0191-8598-000000000017 | >>>> SUMMARY | localhost | Provision instances | 285.25s >>>> 2021-08-24 10:21:18.500868 | 52540075-9baf-0191-8598-000000000014 | >>>> SUMMARY | localhost | Reserve instances | 6.08s >>>> 2021-08-24 10:21:18.501228 | 52540075-9baf-0191-8598-000000000019 | >>>> SUMMARY | localhost | Provision instance network ports | 3.72s >>>> 2021-08-24 10:21:18.501588 | 52540075-9baf-0191-8598-000000000013 | >>>> SUMMARY | localhost | Find existing instances | 1.52s >>>> 2021-08-24 10:21:18.501944 | 52540075-9baf-0191-8598-000000000012 | >>>> SUMMARY | localhost | Expand roles | 0.92s >>>> 2021-08-24 10:21:18.502281 | 52540075-9baf-0191-8598-00000000000c | >>>> SUMMARY | localhost | stat overcloud-full.raw | 0.26s >>>> 2021-08-24 10:21:18.502706 | 52540075-9baf-0191-8598-00000000000d | >>>> SUMMARY | localhost | stat overcloud-full.initrd | 0.19s >>>> 2021-08-24 10:21:18.503053 | 52540075-9baf-0191-8598-00000000000e | >>>> SUMMARY | localhost | Set file based default image | 0.04s >>>> 2021-08-24 10:21:18.503419 | 52540075-9baf-0191-8598-000000000018 | >>>> SUMMARY | localhost | Metalsmith log for provision instances | 0.04s >>>> 2021-08-24 10:21:18.503806 | 52540075-9baf-0191-8598-000000000016 | >>>> SUMMARY | localhost | Set concurrency fact | 0.04s >>>> 2021-08-24 10:21:18.504139 | 52540075-9baf-0191-8598-000000000015 | >>>> SUMMARY | localhost | Metalsmith log for reserve instances | 0.04s >>>> 2021-08-24 10:21:18.504469 | 52540075-9baf-0191-8598-00000000000f | >>>> SUMMARY | localhost | Set whole-disk file based default image | 0.03s >>>> 2021-08-24 10:21:18.504849 | 52540075-9baf-0191-8598-000000000010 | >>>> SUMMARY | localhost | Set glance based default image | 0.03s >>>> 2021-08-24 10:21:18.505246 | 52540075-9baf-0191-8598-000000000009 | >>>> SUMMARY | localhost | fail | 0.03s >>>> 2021-08-24 10:21:18.505627 | 52540075-9baf-0191-8598-000000000008 | >>>> SUMMARY | localhost | fail | 0.03s >>>> 2021-08-24 10:21:18.505987 | 52540075-9baf-0191-8598-00000000000a | >>>> SUMMARY | localhost | fail | 0.02s >>>> 2021-08-24 10:21:18.506315 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >>>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.506693 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State >>>> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.507032 | ~~~~~~~~~~~~~~~~~~ Number of nodes which >>>> did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >>>> 2021-08-24 10:21:18.507351 | The following node(s) had failures: >>>> localhost >>>> 2021-08-24 10:21:18.507720 | >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Temporary directory [ /tmp/tripleob9lxg9vi ] cleaned up >>>> Ansible execution failed. playbook: >>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>> Status: failed, Return Code: 2 >>>> Temporary directory [ /tmp/tripleoyso22wsn ] cleaned up >>>> Exception occured while running the command >>>> Traceback (most recent call last): >>>> File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", >>>> line 34, in run >>>> super(Command, self).run(parsed_args) >>>> File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", >>>> line 39, in run >>>> return super(Command, self).run(parsed_args) >>>> File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, >>>> in run >>>> return_code = self.take_action(parsed_args) or 0 >>>> File >>>> "/usr/lib/python3.6/site-packages/tripleoclient/v2/overcloud_node.py", line >>>> 323, in take_action >>>> extra_vars=extra_vars, >>>> File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line >>>> 724, in run_ansible_playbook >>>> raise RuntimeError(err_msg) >>>> RuntimeError: Ansible execution failed. playbook: >>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>> Status: failed, Return Code: 2 >>>> Ansible execution failed. playbook: >>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>> Status: failed, Return Code: 2 >>>> clean_up ProvisionNode: Ansible execution failed. playbook: >>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>> Status: failed, Return Code: 2 >>>> END return value: 1 >>>> >>> >>> Here is my baremetal_deployment.yaml file : >>> >>>> - name: Controller >>>> count: 1 >>>> hostname_format: controller-%index% >>>> 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: /home/stack/templates/nic-configs/bonds_vlans.j2 >>>> default_route_network: >>>> - external >>>> - name: ComputeHCI >>>> count: 1 >>>> hostname_format: computehci-%index% >>>> defaults: >>>> profile: computeHCI >>>> networks: >>>> - network: internal_api >>>> subnet: internal_api_subnet02 >>>> - network: tenant >>>> subnet: tenant_subnet02 >>>> - network: storage >>>> subnet: storage_subnet02 >>>> - network: storage_mgmt >>>> subnet: storage_mgmt_subnet02 >>>> network_config: >>>> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >>>> >>> >>> >>> If someone can help me and point me where to look. >>> Any help will be appreciated. >>> >>> Regards. >>> >>> Le lun. 23 août 2021 à 12:48, wodel youchi a >>> écrit : >>> >>>> 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 rosmaita.fossdev at gmail.com Tue Aug 24 17:34:28 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 24 Aug 2021 13:34:28 -0400 Subject: [cinder] reminder: this week's meeting in video+IRC Message-ID: <078f192b-5c8d-c742-366a-ca354af43142@gmail.com> Quick reminder that this week's Cinder team meeting on Wednesday 25 August, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. These are the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. * The meeting will be recorded. connection info: https://bluejeans.com/3228528973 meeting agenda: https://etherpad.opendev.org/p/cinder-xena-meetings cheers, brian From radoslaw.piliszek at gmail.com Tue Aug 24 17:35:56 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 24 Aug 2021 19:35:56 +0200 Subject: What is this error, does it effect the install? In-Reply-To: <021f01d7990c$de474930$9ad5db90$@163.com> References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> <021f01d7990c$de474930$9ad5db90$@163.com> Message-ID: On Tue, Aug 24, 2021 at 7:24 PM Tommy Sway wrote: > > Could you please tell me again that when kolla tool is used for formal deployment, if there are failed steps or nodes are damaged in the middle, is it ok for me to reinstall a new node, add it in and run the deployment command again? > I've heard that Ansible-based deployments are generally idempotent, so that shouldn't be a problem. > Isn't it? > Thank you very much! > Yes, we have designed our playbooks to be idempotent. Please let us know if they are not. Ensuring idempotence is not a trivial task. :-) -yoctozepto > > -----Original Message----- > From: Radosław Piliszek > Sent: Tuesday, August 24, 2021 10:33 PM > To: Tommy Sway > Cc: openstack-discuss > Subject: Re: What is this error, does it effect the install? > > On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > > > > > # kolla-ansible -i ./multinode prechecks > > > > > > > > > > > > PLAY RECAP > > ********************************************************************** > > ***************************************** > > > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > > > > > > > The error is : > > > > > > > > The full traceback is: > > > > Traceback (most recent call last): > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 102, in > > > > _ansiballz_main() > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 94, in _ansiballz_main > > > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > > init_globals=None, run_name='__main__', alter_sys=True) > > > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > > > return _run_module_code(code, init_globals, run_name, mod_spec) > > > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > > > mod_name, mod_spec, pkg_name, script_name) > > > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > > > exec(code, run_globals) > > > > File > > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_con > > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > > line 18, in > > > > ModuleNotFoundError: No module named 'docker' > > > > fatal: [localhost]: FAILED! => { > > > > "changed": false, > > > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > > > "module_stdout": "", > > > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > > > "rc": 1 > > > > } > > > > > > > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > > > > > What is it ? And does it effect the install ? > > > > > > It's a minor bug in that the tooling should not be trying to check docker on localhost. > It should be fine to progress ignoring this particular issue. > > -yoctozepto > > From tonykarera at gmail.com Tue Aug 24 17:36:46 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 24 Aug 2021 19:36:46 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Ammad, There is no directory or log relevant to heat in the /var/log directory Regards Tony Karera On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed wrote: > Hi Karera, > > Login to master node and check the logs of heat agent in var log. There > must be something the cluster is stucking somewhere in creating. > > Ammad > > On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: > >> Hello Ammad, >> >> I had done as explained and it worked upto a certain point. The master >> node was created but the cluster remained in Creation in progress for over >> an hour and failed with error below >> >> Stack Faults >> as follows: >> default-master >> Timed out >> default-worker >> Timed out >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: >> >>> Hi Tony, >>> >>> You can try by creating your private vxlan network prior to >>> deployment of cluster and explicitly create your cluster in vxlan network. >>> >>> --fixed-network private --fixed-subnet private-subnet >>> >>> You can specify above while creating a cluster. >>> >>> Ammad >>> >>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >>> wrote: >>> >>>> Hello MOhamed, >>>> >>>> I think the Kubernetes cluster is ok but it when I deploy it, It >>>> creates a fixed network using vlan which I am not using for internal >>>> networks. >>>> >>>> When I create a a vxlan Network and use it in the cluster creation, It >>>> fails. Is there a trick around this ? >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Fri, Aug 20, 2021 at 9:00 AM feilong >>>> wrote: >>>> >>>>> 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. >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Tue Aug 24 17:38:16 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 24 Aug 2021 19:38:16 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Bharat, Only the Master node gets created. There is no heat container agent on the compute node. Regards Tony Karera On Tue, Aug 24, 2021 at 12:45 PM Bharat Kunwar wrote: > Were master and worker nodes created? Did you log into the nodes and look > at heat container agent logs under /var/log/heat-config/ ? > > On 24 Aug 2021, at 11:41, Karera Tony wrote: > > Hello Ammad, > > I had done as explained and it worked upto a certain point. The master > node was created but the cluster remained in Creation in progress for over > an hour and failed with error below > > Stack Faults > as follows: > default-master > Timed out > default-worker > Timed out > > > Regards > > Tony Karera > > > > > On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: > >> Hi Tony, >> >> You can try by creating your private vxlan network prior to deployment of >> cluster and explicitly create your cluster in vxlan network. >> >> --fixed-network private --fixed-subnet private-subnet >> >> You can specify above while creating a cluster. >> >> Ammad >> >> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >> wrote: >> >>> Hello MOhamed, >>> >>> I think the Kubernetes cluster is ok but it when I deploy it, It creates >>> a fixed network using vlan which I am not using for internal networks. >>> >>> When I create a a vxlan Network and use it in the cluster creation, It >>> fails. Is there a trick around this ? >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >>> >>>> 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. >>>> ------------------------------------------------------------------------------ >>>> >>>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Tue Aug 24 17:38:57 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Tue, 24 Aug 2021 22:38:57 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Then check journalctl -xe or status of heat agent service status. Ammad On Tue, Aug 24, 2021 at 10:36 PM Karera Tony wrote: > Hello Ammad, > > There is no directory or log relevant to heat in the /var/log directory > > Regards > > Tony Karera > > > > > On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed wrote: > >> Hi Karera, >> >> Login to master node and check the logs of heat agent in var log. There >> must be something the cluster is stucking somewhere in creating. >> >> Ammad >> >> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: >> >>> Hello Ammad, >>> >>> I had done as explained and it worked upto a certain point. The master >>> node was created but the cluster remained in Creation in progress for over >>> an hour and failed with error below >>> >>> Stack Faults >>> as follows: >>> default-master >>> Timed out >>> default-worker >>> Timed out >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed >>> wrote: >>> >>>> Hi Tony, >>>> >>>> You can try by creating your private vxlan network prior to >>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>> >>>> --fixed-network private --fixed-subnet private-subnet >>>> >>>> You can specify above while creating a cluster. >>>> >>>> Ammad >>>> >>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >>>> wrote: >>>> >>>>> Hello MOhamed, >>>>> >>>>> I think the Kubernetes cluster is ok but it when I deploy it, It >>>>> creates a fixed network using vlan which I am not using for internal >>>>> networks. >>>>> >>>>> When I create a a vxlan Network and use it in the cluster creation, It >>>>> fails. Is there a trick around this ? >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong >>>>> wrote: >>>>> >>>>>> 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. >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> Syed Ammad Ali >>>> >>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Aug 24 17:45:24 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 24 Aug 2021 18:45:24 +0100 Subject: What is this error, does it effect the install? In-Reply-To: <021f01d7990c$de474930$9ad5db90$@163.com> References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> <021f01d7990c$de474930$9ad5db90$@163.com> Message-ID: <115208c01597dabd1147fe9a01b0a6d592ccb44f.camel@redhat.com> On Wed, 2021-08-25 at 01:24 +0800, Tommy Sway wrote: > Could you please tell me again that when kolla tool is used for formal deployment, if there are failed steps or nodes are damaged in the middle, is it ok for me to reinstall a new node, add it in and run the deployment command again? > I've heard that Ansible-based deployments are generally idempotent, so that shouldn't be a problem. > Isn't it? it kind of depends on what faild and where. you willl ahve to rebootstrap the node if you reinstall it. most of the time if somethign fails with kolla you can just fix the problem in your config or whatever caused it and re run deploy. you generally shoudl not need to reinstall the os. running kolla-ansible destory will generally clean up the env fully if it comes to that. if you do remove the node and try to re add it its generally better not to reuse hostnames. you can but then you might need to do service specific cleanups in some cases. in this partical case it was jsut complaing that localhost does not have docker. localhost (presumable your laptop/desktop) does not need docker unless you intende to buidl the kolla images your self inwhich case the fix is just install docker and if you run prechecks again it should pass. > Thank you very much! > > > > -----Original Message----- > From: Radosław Piliszek > Sent: Tuesday, August 24, 2021 10:33 PM > To: Tommy Sway > Cc: openstack-discuss > Subject: Re: What is this error, does it effect the install? > > On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > > > > > # kolla-ansible -i ./multinode prechecks > > > > > > > > > > > > PLAY RECAP > > ********************************************************************** > > ***************************************** > > > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > > > > > > > The error is : > > > > > > > > The full traceback is: > > > > Traceback (most recent call last): > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 102, in > > > > _ansiballz_main() > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 94, in _ansiballz_main > > > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-2636009320373 > > 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > > init_globals=None, run_name='__main__', alter_sys=True) > > > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > > > return _run_module_code(code, init_globals, run_name, mod_spec) > > > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > > > mod_name, mod_spec, pkg_name, script_name) > > > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > > > exec(code, run_globals) > > > > File > > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_con > > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > > line 18, in > > > > ModuleNotFoundError: No module named 'docker' > > > > fatal: [localhost]: FAILED! => { > > > > "changed": false, > > > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > > > "module_stdout": "", > > > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > > > "rc": 1 > > > > } > > > > > > > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > > > > > What is it ? And does it effect the install ? > > > > > > It's a minor bug in that the tooling should not be trying to check docker on localhost. > It should be fine to progress ignoring this particular issue. > > -yoctozepto > > > From sz_cuitao at 163.com Tue Aug 24 18:05:03 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Wed, 25 Aug 2021 02:05:03 +0800 Subject: What is this error, does it effect the install? In-Reply-To: <115208c01597dabd1147fe9a01b0a6d592ccb44f.camel@redhat.com> References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> <021f01d7990c$de474930$9ad5db90$@163.com> <115208c01597dabd1147fe9a01b0a6d592ccb44f.camel@redhat.com> Message-ID: <023601d79912$90c09440$b241bcc0$@163.com> This error maybe because the internet download speed is too slow, can I change the docker registry source to resolve it ? fatal: [network02]: FAILED! => {"changed": true, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.41/images/create?tag=wallaby&fromImage=kolla%2Fcentos-binary-neutron-openvswitch-agent\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1199, in main\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 850, in recreate_or_restart_container\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 868, in start_container\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 650, in pull_image\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.APIError: 500 Server Error for http+docker://localhost/v1.41/images/create?tag=wallaby&fromImage=kolla%2Fcentos-binary-neutron-openvswitch-agent: Internal Server Error (\"Get \"https://registry-1.docker.io/v2/\": context deadline exceeded\")\\n'"} -----Original Message----- From: Sean Mooney Sent: Wednesday, August 25, 2021 1:45 AM To: Tommy Sway ; 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: Re: What is this error, does it effect the install? On Wed, 2021-08-25 at 01:24 +0800, Tommy Sway wrote: > Could you please tell me again that when kolla tool is used for formal deployment, if there are failed steps or nodes are damaged in the middle, is it ok for me to reinstall a new node, add it in and run the deployment command again? > I've heard that Ansible-based deployments are generally idempotent, so that shouldn't be a problem. > Isn't it? it kind of depends on what faild and where. you willl ahve to rebootstrap the node if you reinstall it. most of the time if somethign fails with kolla you can just fix the problem in your config or whatever caused it and re run deploy. you generally shoudl not need to reinstall the os. running kolla-ansible destory will generally clean up the env fully if it comes to that. if you do remove the node and try to re add it its generally better not to reuse hostnames. you can but then you might need to do service specific cleanups in some cases. in this partical case it was jsut complaing that localhost does not have docker. localhost (presumable your laptop/desktop) does not need docker unless you intende to buidl the kolla images your self inwhich case the fix is just install docker and if you run prechecks again it should pass. > Thank you very much! > > > > -----Original Message----- > From: Radosław Piliszek > Sent: Tuesday, August 24, 2021 10:33 PM > To: Tommy Sway > Cc: openstack-discuss > Subject: Re: What is this error, does it effect the install? > > On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > > > > > # kolla-ansible -i ./multinode prechecks > > > > > > > > > > > > PLAY RECAP > > ******************************************************************** > > ** > > ***************************************** > > > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > > > > > > > The error is : > > > > > > > > The full traceback is: > > > > Traceback (most recent call last): > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 102, in > > > > _ansiballz_main() > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 94, in > > _ansiballz_main > > > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > > > > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > > init_globals=None, run_name='__main__', alter_sys=True) > > > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > > > return _run_module_code(code, init_globals, run_name, mod_spec) > > > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > > > mod_name, mod_spec, pkg_name, script_name) > > > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > > > exec(code, run_globals) > > > > File > > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_c > > on > > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > > line 18, in > > > > ModuleNotFoundError: No module named 'docker' > > > > fatal: [localhost]: FAILED! => { > > > > "changed": false, > > > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > > > "module_stdout": "", > > > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > > > "rc": 1 > > > > } > > > > > > > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > > > > > What is it ? And does it effect the install ? > > > > > > It's a minor bug in that the tooling should not be trying to check docker on localhost. > It should be fine to progress ignoring this particular issue. > > -yoctozepto > > > From mnaser at vexxhost.com Tue Aug 24 18:11:54 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 24 Aug 2021 14:11:54 -0400 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Also check out /var/log/cloud-init.log :) On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed wrote: > > Then check journalctl -xe or status of heat agent service status. > > > Ammad > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony wrote: >> >> Hello Ammad, >> >> There is no directory or log relevant to heat in the /var/log directory >> >> Regards >> >> Tony Karera >> >> >> >> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed wrote: >>> >>> Hi Karera, >>> >>> Login to master node and check the logs of heat agent in var log. There must be something the cluster is stucking somewhere in creating. >>> >>> Ammad >>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: >>>> >>>> Hello Ammad, >>>> >>>> I had done as explained and it worked upto a certain point. The master node was created but the cluster remained in Creation in progress for over an hour and failed with error below >>>> >>>> Stack Faults >>>> as follows: >>>> default-master >>>> Timed out >>>> default-worker >>>> Timed out >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: >>>>> >>>>> Hi Tony, >>>>> >>>>> You can try by creating your private vxlan network prior to deployment of cluster and explicitly create your cluster in vxlan network. >>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>> >>>>> You can specify above while creating a cluster. >>>>> >>>>> Ammad >>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony wrote: >>>>>> >>>>>> Hello MOhamed, >>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It creates a fixed network using vlan which I am not using for internal networks. >>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster creation, It fails. Is there a trick around this ? >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >>>>>>> >>>>>>> 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. >>>>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >>> >>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali > > -- > Regards, > > > Syed Ammad Ali -- Mohammed Naser VEXXHOST, Inc. From gouthampravi at gmail.com Tue Aug 24 18:21:30 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Tue, 24 Aug 2021 11:21:30 -0700 Subject: [devstack][neutron][manila] Instances having trouble getting to external network with OVN In-Reply-To: References: Message-ID: Hi, Bubbling up this issue - I reported a launchpad bug with some more debug information: https://bugs.launchpad.net/bugs/1939627 I’m confused how/why only the Manila gates are hitting this issue. If you’re reading - do you have any tests elsewhere that setup a nova instance on a devstack and ping/communicate with the internet/outside world? If yes, I’d love to compare configuration with your setup. Thank you so much for your help, Goutham On Wed, Jul 21, 2021 at 12:07 PM Goutham Pacha Ravi wrote: > On Wed, Jul 14, 2021 at 2:21 PM Carlos Silva > wrote: > >> Hello, >> >> NetApp CI has been facing the same problem. >> > > Thank you Carlos! > > >> >> Here is a local.conf we have been using in our CI: >> https://paste.openstack.org/show/807484/ >> The tests had basically same output described by Goutham: >> https://paste.openstack.org/show/807486/ >> >> I have also tried this in a development environment in our lab but the >> same issue is occurring. >> >> >> Em ter., 13 de jul. de 2021 às 18:20, Goutham Pacha Ravi < >> gouthampravi at gmail.com> escreveu: >> >>> Hi, >>> >>> Some third party storage CI running against manila repos has had issues >>> setting up VMs and providing access to external resources in devstack; >>> these issues started around the time that the default ml2 plugin was >>> switched to OVN. Folks in the manila team aren't familiar with devstack/CI >>> networking to determine how to resolve these; and we'd totally appreciate >>> help from networking experts in this regard. >>> >>> A sample local.conf file used by the CI is here: >>> http://paste.openstack.org/show/807449/ >>> >>> Manila's tests: >>> - create a private tenant network >>> - setup a router that connects the private network to the public >>> network >>> - create a nova VM on the private tenant network >>> - attempt to mount a share via NFS from within this VM >>> >>> The final step fails because the NFS mount command times out within the >>> test VM: >>> >>> tempest.lib.exceptions.SSHExecCommandFailed: Command 'sudo mount -vt nfs >>> "10.16.xx.xx:/share-96ae8d0c-8bab-4fcd-b278-51a6f473e03c-manila" /mnt', >>> exit status: 32, stderr: >>> mount.nfs: mount(2): Connection timed out >>> mount.nfs: Connection timed out >>> >>> >>> stdout: >>> mount.nfs: timeout set for Mon Jun 28 14:47:19 2021 >>> mount.nfs: trying text-based options >>> 'vers=4.2,addr=10.16.xx.xx,clientaddr=10.1.0.26' >>> >>> >>> >>> The timeout seems to be because the VM is unable to reach the NFS server >>> that's external to the devstack host. The NFS server is reachable from the >>> devstack host. >>> >>> Have there been any changes to devstack configuration that we need to be >>> aware of, wrt VMs having access to the external network? >>> >>> Thanks, >>> Goutham >>> >> > Ping Neutron developers, > > Can you help vet this devstack issue; folks in the manila third party CI > community will be happy to share further logs or details. > As an example, failure logs on a third party CI job are here: > http://openstack-logs.purestorage.com/84/789384/25/thirdparty-check/pure-devstack-manila-tempest-aio/6965033/ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Tue Aug 24 22:56:38 2021 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Wed, 25 Aug 2021 07:56:38 +0900 Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations ending in less than 1 hour In-Reply-To: References: Message-ID: A final quick reminder that we are in the last hour for declaring PTL and TC candidacies. Nominations are open until Aug 24, 2021 23:45 UTC. Nominations started @ 2021-08-17 23:45:00 UTC Nominations end @ 2021-08-24 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 0:50:19 Nominations progress : 99.50% --------------------------------------------------- Projects[1] : 47 Projects with candidates : 39 ( 82.98%) Projects with election : 1 ( 2.13%) --------------------------------------------------- Need election : 1 (Cyborg) Need appointment : 8 (Adjutant Heat Magnum Monasca Puppet_OpenStack Sahara Swift Zun) =================================================== Stats gathered @ 2021-08-24 22:54:41 UTC Thank you, Ian Y. Choi (ianychoi) On behalf of all the Election Officials [1] These numbers include the following projects that have a candidate that is approved my only a single election official: On Tue, Aug 24, 2021 at 2:10 AM Amy Marrich wrote: > A quick reminder that we are in the last hours for declaring PTL and > TC candidacies. Nominations are open until Aug 24, 2021 23:45 UTC. > > If you want to stand for election, don't delay, follow the > instructions at [1] to make sure the community knows your > intentions. > > Make sure your nomination has been submitted to the > openstack/election repository and approved by election officials. > > Election statistics[2]: > Nominations started @ 2021-08-17 23:45:00 UTC > Nominations end @ 2021-08-24 23:45:00 UTC > Nominations duration : 7 days, 0:00:00 > Nominations remaining : 1 day, 7:37:12 > Nominations progress : 81.18% > --------------------------------------------------- > Projects[1] : 47 > Projects with candidates : 28 ( 52.00%) > Projects with election : 1 ( 2.00%) > --------------------------------------------------- > Need election : 1 (Cyborg) > Need appointment : 19 (Adjutant Cinder Cloudkitty Designate Heat Ironic Magnum Manila Monasca OpenStack_Charms Openstack_Chef Puppet_OpenStack Release_Management Requirements Sahara Storlets Swift Tripleo Zun) > =================================================== > Stats gathered @ 2021-08-23 16:07:48 UTC > > > This means that with approximately 2 days left, 23 projects > will be deemed leaderless. In this case the TC will oversee PTL > selection as described by [3]. > > There are also currently 4 confirmed candidates for the 4 open Technical Committee. > > Thank you, > > Amy (spotz) > > On behalf of all the Election Officials > > > [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy > [2] Any open reviews at > https://review.openstack.org/#/q/is:open+project:openstack/election > have not been factored into these stats. > [3] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Tue Aug 24 23:23:40 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 24 Aug 2021 16:23:40 -0700 Subject: =?UTF-8?Q?Re:_[devstack][neutron][manila]_Instances_having_trouble_getti?= =?UTF-8?Q?ng_to_external_network_with_OVN?= In-Reply-To: References: Message-ID: On Tue, Aug 24, 2021, at 11:21 AM, Goutham Pacha Ravi wrote: > Hi, > > Bubbling up this issue - I reported a launchpad bug with some more > debug information: > https://bugs.launchpad.net/bugs/1939627 > > I’m confused how/why only the Manila gates are hitting this issue. If > you’re reading - do you have any tests elsewhere that setup a nova > instance on a devstack and ping/communicate with the internet/outside > world? If yes, I’d love to compare configuration with your setup. It has been a while since I looked at this stuff and the OVN switch may have changed it, but we have historically intentionally avoided external connectivity for the nested devstack cloud in upstream CI. Instead we expect the test jobs to be self contained. On multinode jobs we set up an entire L2 network with very simple L3 routing that is independent of the host system networking with vxlan. This allows tempest to talk to the test instances on the nested cloud. But those nested cloud instances cannot get off the instance. This is important because it helps keep things like dhcp requests from leaking out into the world. Even if you configured floating IPs on the inner instances those IPs wouldn't be routable to the host instance in the clouds that we host jobs in. To make this work without a bunch of support from the hosting environment you would need to NAT between the host instances IP and inner nested devstack instances so that traffic exiting the test instances had a path to the outside world that can receive the return traffic. In https://bugs.launchpad.net/bugs/1939627 you are creating an external network and floating IPs but once that traffic leaves the host system there must be a return path for any responses, and I suspect that is what is missing? It is odd that this would coincide with the OVN change. Maybe IP ranges were updated with the OVN change and any hosting support that enabled routing of those IPs is no longer valid as a result? > > Thank you so much for your help, > > Goutham > From tburke at nvidia.com Tue Aug 24 23:59:55 2021 From: tburke at nvidia.com (Timothy Burke) Date: Tue, 24 Aug 2021 23:59:55 +0000 Subject: [election][swift] PTL candidacy for Yoga Message-ID: It would be my pleasure to continue serving as Swift PTL for the Yoga cycle. This past cycle, we have continued our commitment to operational excellence. We've improved several features vital to large clusters, such as container sharding, partition power increases, and storage-policy reconciliation. We've improved the durability of erasure-coded data immediately after a write. We've made our logs, metrics, and errors more useful. We focus on operators for several reasons. Operators are at the junction of the software we write, the hardware we use, and the clients we serve. They have perhaps the best perspective to see the value-to-effort ratio of prospective improvements. They run the experiments that establish and optimize deployment patterns. They manage the drives and networking that allow us to serve hundreds of petabytes at terabits per second, and their projections tell us that storage must become bigger and faster. Thinking like an operator, there are several areas where Swift should improve. Replication and reconstruction continue to be a delicate balancing act between moving data for the sake of expansion vs. ensuring durability. We need a better handle on which data gets accessed, how frequently, and with what sort of performance -- ideally indexed by tenant and even user. As more clusters are stood up in more regions, we need to improve monitoring and recovery such that clusters can run with minimal human intervention. I look forward to working with the community to bring Swift into a future of ever-larger and ever-more-numerous clusters. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Wed Aug 25 00:07:00 2021 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Wed, 25 Aug 2021 09:07:00 +0900 Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations End Message-ID: The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 6 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Heat, Monasca, Puppet_OpenStack, Sahara, Zun There is 1 project that will have elections: Cyborg. Polling will start Aug 31, 2021 23:45 UTC. -- TC Election Details -- Now begins the campaigning period where candidates and electorate may debate their statements. Thank you, Ian Y. Choi (ianychoi) On behalf of all the Election Officials [0] https://governance.openstack.org/election/#yoga-ptl-candidates [1] https://governance.openstack.org/election/#yoga-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Wed Aug 25 00:07:03 2021 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Wed, 25 Aug 2021 09:07:03 +0900 Subject: [all][elections][tc] TC Campaigning Kickoff Message-ID: Developers, The TC Election Campaigning Period has now started [1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms [2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform [2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. Ian Y. Choi (ianychoi) On behalf of all the Election Officials [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/yoga/TC -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Wed Aug 25 00:55:04 2021 From: amy at demarco.com (Amy Marrich) Date: Tue, 24 Aug 2021 19:55:04 -0500 Subject: [all][elections][tc] Technical Committee Election Results Message-ID: As there were 4 empty seats and 4 candidates for those TC positions, no campaigning or voting was necessary. Please join me in congratulating the 4 returning members of the Technical Committee (TC). Dan Smith () Ghanshyam Mann (gmann) Jay Bryant (jungleboyj) Kendall Nelson (diablo_rojo) Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates and if you are considering running in the future please join the #openstack-tc channel and see what is involved if you haven't already. Thanks, Amy (spotz) on behalf of all the Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Wed Aug 25 06:17:18 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Wed, 25 Aug 2021 14:17:18 +0800 Subject: What is this error, does it effect the install? In-Reply-To: <023601d79912$90c09440$b241bcc0$@163.com> References: <01de01d798f3$8b7403b0$a25c0b10$@163.com> <021f01d7990c$de474930$9ad5db90$@163.com> <115208c01597dabd1147fe9a01b0a6d592ccb44f.camel@redhat.com> <023601d79912$90c09440$b241bcc0$@163.com> Message-ID: <025401d79978$dbce88f0$936b9ad0$@163.com> Can I change Docker registry to use my local one in advance? If possible, do I need to synchronize registry in advance? Is there any guidance? -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Wednesday, August 25, 2021 2:05 AM To: 'Sean Mooney' ; 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: What is this error, does it effect the install? This error maybe because the internet download speed is too slow, can I change the docker registry source to resolve it ? fatal: [network02]: FAILED! => {"changed": true, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.41/images/create?tag=wallaby&fromImage=kolla%2Fcentos-binary-neutron-openvswitch-agent\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1199, in main\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 850, in recreate_or_restart_container\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 868, in start_container\\n File \"/tmp/ansible_kolla_docker_payload_nob6zdmd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 650, in pull_image\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.APIError: 500 Server Error for http+docker://localhost/v1.41/images/create?tag=wallaby&fromImage=kolla%2Fcentos-binary-neutron-openvswitch-agent: Internal Server Error (\"Get \"https://registry-1.docker.io/v2/\": context deadline exceeded\")\\n'"} -----Original Message----- From: Sean Mooney Sent: Wednesday, August 25, 2021 1:45 AM To: Tommy Sway ; 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: Re: What is this error, does it effect the install? On Wed, 2021-08-25 at 01:24 +0800, Tommy Sway wrote: > Could you please tell me again that when kolla tool is used for formal deployment, if there are failed steps or nodes are damaged in the middle, is it ok for me to reinstall a new node, add it in and run the deployment command again? > I've heard that Ansible-based deployments are generally idempotent, so that shouldn't be a problem. > Isn't it? it kind of depends on what faild and where. you willl ahve to rebootstrap the node if you reinstall it. most of the time if somethign fails with kolla you can just fix the problem in your config or whatever caused it and re run deploy. you generally shoudl not need to reinstall the os. running kolla-ansible destory will generally clean up the env fully if it comes to that. if you do remove the node and try to re add it its generally better not to reuse hostnames. you can but then you might need to do service specific cleanups in some cases. in this partical case it was jsut complaing that localhost does not have docker. localhost (presumable your laptop/desktop) does not need docker unless you intende to buidl the kolla images your self inwhich case the fix is just install docker and if you run prechecks again it should pass. > Thank you very much! > > > > -----Original Message----- > From: Radosław Piliszek > Sent: Tuesday, August 24, 2021 10:33 PM > To: Tommy Sway > Cc: openstack-discuss > Subject: Re: What is this error, does it effect the install? > > On Tue, Aug 24, 2021 at 4:23 PM Tommy Sway wrote: > > > > I try to install Openstack using kolla, but it’s a error when I check the system before installation : > > > > > > > > # kolla-ansible -i ./multinode prechecks > > > > > > > > > > > > PLAY RECAP > > ******************************************************************** > > ** > > ***************************************** > > > > compute01 : ok=28 changed=0 unreachable=0 failed=0 skipped=24 rescued=0 ignored=0 > > > > control01 : ok=65 changed=0 unreachable=0 failed=0 skipped=59 rescued=0 ignored=0 > > > > control02 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > control03 : ok=62 changed=0 unreachable=0 failed=0 skipped=53 rescued=0 ignored=0 > > > > localhost : ok=6 changed=0 unreachable=0 failed=1 skipped=2 rescued=0 ignored=0 > > > > monitoring01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > network01 : ok=47 changed=0 unreachable=0 failed=0 skipped=109 rescued=0 ignored=0 > > > > network02 : ok=47 changed=0 unreachable=0 failed=0 skipped=105 rescued=0 ignored=0 > > > > storage01 : ok=18 changed=0 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 > > > > > > > > > > > > The error is : > > > > > > > > The full traceback is: > > > > Traceback (most recent call last): > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 102, in > > > > _ansiballz_main() > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 94, in > > _ansiballz_main > > > > invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) > > > > File > > "/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-26360093203 > > 73 31/AnsiballZ_kolla_container_facts.py", line 40, in invoke_module > > > > > > runpy.run_module(mod_name='ansible.modules.kolla_container_facts', > > init_globals=None, run_name='__main__', alter_sys=True) > > > > File "/usr/lib64/python3.6/runpy.py", line 205, in run_module > > > > return _run_module_code(code, init_globals, run_name, mod_spec) > > > > File "/usr/lib64/python3.6/runpy.py", line 96, in _run_module_code > > > > mod_name, mod_spec, pkg_name, script_name) > > > > File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code > > > > exec(code, run_globals) > > > > File > > "/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_c > > on > > tainer_facts_payload.zip/ansible/modules/kolla_container_facts.py", > > line 18, in > > > > ModuleNotFoundError: No module named 'docker' > > > > fatal: [localhost]: FAILED! => { > > > > "changed": false, > > > > "module_stderr": "Traceback (most recent call last):\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 102, in \n _ansiballz_main()\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/root/.ansible/tmp/ansible-tmp-1629813578.505786-101978-263600932037331/AnsiballZ_kolla_container_facts.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_kolla_container_facts_payload_v95779u3/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 18, in \nModuleNotFoundError: No module named 'docker'\n", > > > > "module_stdout": "", > > > > "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", > > > > "rc": 1 > > > > } > > > > > > > > > > > > I installed the docker package on the deploy localhost and run again, but it still raise the same error. > > > > > > > > What is it ? And does it effect the install ? > > > > > > It's a minor bug in that the tooling should not be trying to check docker on localhost. > It should be fine to progress ignoring this particular issue. > > -yoctozepto > > > From kkchn.in at gmail.com Wed Aug 25 06:18:48 2021 From: kkchn.in at gmail.com (KK CHN) Date: Wed, 25 Aug 2021 11:48:48 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> References: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> Message-ID: Thank you all. I am able to get the Single disk Windows VM exported from HyperV and imported to OpenStack(Ussuri, Glance and Qemu KVM ) Instance launched and its showing the status running in the PowerState Tab of Horizon dashboard. (need to check with the administrator user to login and confirm the VM is working as expected . ) My second phase : I need to perform importing multiple disk Windows VM to my OpenStack setup . ( For single disk Windows vhdx file, I 've converted it to qcow2 file and imported to OpenStack as the steps I posted in my previous emails. ) Now how can I import Multiple disk Windows VM to OpenStack. First Step is to convert the vhdx files exported from HyperV to qcow2 files. After this step , what steps need to be performed to bring a multi disk Windows VM to OpeStack ? For Eg: I have a Windows VM 1. with Application server 1TB single disk image exported from hyperV. This I can import to my OpenStack setup with the steps I followed in my earlier emails as it is a single disk image. 2. A Database server for the above application with 700 GB in multiple disks. ( 100 and 600 GB disks images exported from HyperV and in vhdx format for DB server) How to bring this server imported to my OpeStack setup (ussuri, glance and QEMU KVM). As this is from Windows HyperV I am new to multidisk environment from Windows. ( for Linux VMs exported from oVirt(RHVM) I am able to import multidisk VMs to OpenStack as they are in LVM and I have to mount it with VG name and adding entries in /etc/fstab file ) But in Windows multi disks how to perform this ? what steps I have to perform to import this to OpenStack. Any hints or suggestions most welcome.. Kris On Tue, Aug 24, 2021 at 1:40 PM Eugen Block wrote: > Of course you need a running nova-conductor, how did you launch VMs before? > > > Zitat von KK CHN : > > > 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 hjensas at redhat.com Wed Aug 25 08:04:23 2021 From: hjensas at redhat.com (Harald Jensas) Date: Wed, 25 Aug 2021 10:04:23 +0200 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> On 8/24/21 7:07 PM, wodel youchi wrote: > *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 | >      FATAL | Render network_config from template | computehci-1 | > error={ >     "censored": "the output has been hidden due to the fact that > 'no_log: true' was specified for this result", >     "changed": false > } This looks like a problem with your nic config template, /home/stack/templates/nic-configs/bonds_vlans.j2. To debug disable "hideing" of sensitive logs. sudo sed -i 's/tripleo_network_config_hide_sensitive_logs: true/tripleo_network_config_hide_sensitive_logs: false/g' /usr/share/ansible/roles/tripleo-network-config/defaults/main.yml -- Harald From hjensas at redhat.com Wed Aug 25 08:06:54 2021 From: hjensas at redhat.com (Harald Jensas) Date: Wed, 25 Aug 2021 10:06:54 +0200 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: On 8/24/21 2:13 PM, James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle > some of our upcoming challenges — the transition to CentOS/RHEL 9, > increasing complexity around container management, and revisiting our > commitments to our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad.  I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > > -- > -- James Slagle > -- +2, Thanks James! From marcin.juszkiewicz at linaro.org Wed Aug 25 08:41:31 2021 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Wed, 25 Aug 2021 10:41:31 +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: <169ec9ed-9470-cc15-5831-2c6c5e25e866@linaro.org> On 18.08.2021 11:16, Michał Nasiadka wrote: > I’d like to nominate myself to serve as the Kolla PTL for Yoga cycle. +1 (hrw) From massimo.sgaravatto at gmail.com Wed Aug 25 08:54:03 2021 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Wed, 25 Aug 2021 10:54:03 +0200 Subject: [ops] [cinder] Cinder driver for Dell EMC PS Series on Train Message-ID: Dear all In our Cloud we have multiple backends for Cinder. One of them is using the Dell EMC PS Series volume driver My understanding (reading https://docs.openstack.org/releasenotes/cinder/ussuri.html) is that the driver doesn't work anymore in >= Ussuri A while ago we migrated to Train (using CentOS7 as operating system) and everything kept working fine. We are now trying to migrate to CentOS8 (still using Train) and the cinder volume service for the equallogic backend doesn't work anymore In the log file I found something like this [*] We already planned to dismiss that backend (but we planned to do that before next Openstack update). Does anyone know if that driver is supposed to work with Train and CentOS8 (and therefore python3) ? Thanks, Massimo [*] 021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps [req-9fee10a8-4ad4-4bb3-a04c-46ef6919bb0f - - - - -] Error running command.: TypeError: must be str, not bytes 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps Traceback (most recent call last): 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", line 248, in _run_ssh 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps timeout=self.configuration.ssh_conn_timeout) 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", line 72, in __inner 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps res = gt.wait() 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 181, in wait 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps return self._exit_event.wait() 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps result = hub.switch() 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in switch 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps return self.greenlet.switch() 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 221, in main 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps result = function(*args, **kwargs) 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", line 196, in _ssh_execute 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps self._get_output(chan) 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps File "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", line 175, in _get_output 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps out += ret 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps TypeError: must be str, not bytes 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Aug 25 08:57:39 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 25 Aug 2021 10:57:39 +0200 Subject: [kolla][wallaby] update images stop all vms In-Reply-To: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> References: <6c9a2ae47f88ef7928bb40d36ccb55e9ee63a00e.camel@redhat.com> Message-ID: Hello Sean, I reinstalled openstack wallaby with ubuntu source. machinectl command can see running vm in libvirt container and also out of container: oot at tst2-kvm01:/home/ansible# docker exec -it nova_libvirt machinectl list MACHINE CLASS SERVICE OS VERSION ADDRESSES qemu-1-instance-00000003 vm libvirt-qemu oot at tst2-kvm01:/home/ansible# machinectl list MACHINE CLASS SERVICE OS VERSION ADDRESSES qemu-1-instance-00000003 vm libvirt-qemu - I tried to restart the nova_libvirt container: docker restart nova_libvirt and then: oot at tst2-kvm01:/home/ansible# machinectl list No machines. root at tst2-kvm01:/home/ansible# docker exec -it nova_libvirt machinectl list No machines. Ignazio Il giorno mar 24 ago 2021 alle ore 13:35 Sean Mooney ha scritto: > On Tue, 2021-08-24 at 13:00 +0200, Ignazio Cassano wrote: > > I tried again. I started with e new installation of wallaby but this > time I > > used centos source instead of ubuntu source. > > After first deploy I stared a virtual machine. > > Then I update the images and I ran a new deploy. > > Instance went down and in the nova compute log I got the following: > > https://paste.openstack.org/show/808282/ > > i dont know if its the same issue but you might be hitting this > https://bugzilla.redhat.com/show_bug.cgi?id=1963164 > tl;dr is systemd-machined previously did not work inside the contaiener so > livert fell > back to its generic cgroups backend, ignoring machined managing mancines > without it but recently systemd-machined started > working in the contianer. when you upgrade libvirt switches to its > machined backend but it does not have the vms registred in that > so it stopps them. > > > > > > Ignazio > > > > > > Il giorno mar 24 ago 2021 alle ore 09:02 Ignazio Cassano < > > ignaziocassano at gmail.com> ha scritto: > > > > > Hello, about the above issue, we discussed on yesterday on > openstack-kolla > > > IRC. > > > The issue is not related to masakary, but it happens when nova-compute > is > > > redeployed with the following error in > > > linvirt.log: > > > 021-08-24 06:59:25.012+0000: 3224764: info : libvirt version: 6.0.0, > > > package: 0ubuntu8.12 (Christian Ehrhardt < > christian.ehrhardt at canonical.com> > > > Tue, 20 Jul 2021 14:13:56 +0200) > > > 2021-08-24 06:59:25.012+0000: 3224764: info : hostname: tst2-kvm02 > > > 2021-08-24 06:59:25.012+0000: 3224764: error : > > > dnsmasqCapsRefreshInternal:714 : Cannot check dnsmasq binary > > > /usr/sbin/dnsmasq: No such file or directory > > > 2021-08-24 06:59:25.857+0000: 3224822: error : qemuMonitorOpenUnix:292 > : > > > failed to connect to monitor socket: Connection refused > > > 2021-08-24 06:59:25.876+0000: 3224821: error : qemuMonitorOpenUnix:292 > : > > > failed to connect to monitor socket: Connection refused > > > 2021-08-24 06:59:44.670+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-alpha' on this host > > > 2021-08-24 06:59:44.673+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.674+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.677+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-arm' on this host > > > 2021-08-24 06:59:44.681+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-aarch64' on this host > > > 2021-08-24 06:59:44.684+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-cris' on this host > > > 2021-08-24 06:59:44.713+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-lm32' on this host > > > 2021-08-24 06:59:44.716+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-m68k' on this host > > > 2021-08-24 06:59:44.719+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-microblaze' on this host > > > 2021-08-24 06:59:44.721+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-microblazeel' on this host > > > 2021-08-24 06:59:44.725+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips' on this host > > > 2021-08-24 06:59:44.727+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mipsel' on this host > > > 2021-08-24 06:59:44.731+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips64' on this host > > > 2021-08-24 06:59:44.733+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-mips64el' on this host > > > 2021-08-24 06:59:44.736+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc' on this host > > > 2021-08-24 06:59:44.739+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.741+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.744+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64' on this host > > > 2021-08-24 06:59:44.747+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.750+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.753+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-ppc64le' on this host > > > 2021-08-24 06:59:44.755+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-riscv32' on this host > > > 2021-08-24 06:59:44.758+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-riscv64' on this host > > > 2021-08-24 06:59:44.761+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-s390x' on this host > > > 2021-08-24 06:59:44.763+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sh4' on this host > > > 2021-08-24 06:59:44.766+0000: 3224749: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sh4eb' on this host > > > 2021-08-24 06:59:44.768+0000: 3224751: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sparc' on this host > > > 2021-08-24 06:59:44.771+0000: 3224753: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-sparc64' on this host > > > 2021-08-24 06:59:44.773+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-unicore32' on this host > > > 2021-08-24 06:59:44.795+0000: 3224750: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-xtensa' on this host > > > 2021-08-24 06:59:44.798+0000: 3224752: error : > > > virQEMUCapsCacheLookupDefault:5577 : invalid argument: KVM is not > supported > > > by '/usr/bin/qemu-system-xtensaeb' on this host > > > > > > Ignazio > > > > > > Il giorno lun 23 ago 2021 alle ore 17:51 Ignazio Cassano < > > > ignaziocassano at gmail.com> ha scritto: > > > > > > > Hello All, > > > > I am new in kolla so probably my procedure is not correct. > > > > Last week I installed wallaby and I deployed on my openstack only > two > > > > virtual machines. > > > > Today I tried to updated images so: > > > > > > > > 1 pulled new images on my local registry > > > > 2 pushed new images on my local registry > > > > 3 pushed new images from my local registry to controllers and compute > > > > nodes > > > > (kolla-ansible pull --limit control,compute > > > > 4 run kolla-ansible deploy > > > > > > > > All virtual machines went in shutoff state. > > > > What is wrong in my procedure ? > > > > > > > > Regards > > > > Ignazio > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ricardo.SoaresSarto at windriver.com Wed Aug 25 12:12:02 2021 From: Ricardo.SoaresSarto at windriver.com (Soares Sarto, Ricardo) Date: Wed, 25 Aug 2021 12:12:02 +0000 Subject: [horizon][dev] Multiple Login Sessions Message-ID: Hi Everyone, Is there any feature to prevent multiple login sessions for the same user in Horizon? That feature could be used to block a second login attempt for the same user when another session already exists or invalidate the the first session right after a second session is opened by the user. Any reference documentation would be very helpful. Kind regards, rsoaress -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Tue Aug 24 21:08:55 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 24 Aug 2021 22:08:55 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: Message-ID: Hello again, Here is my bond_vlan.j2 is it correct ? --- > {% set mtu_list = [ctlplane_mtu] %} > {% for network in role_networks %} > {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }} > {%- endfor %} > {% set min_viable_mtu = mtu_list | max %} > network_config: > - type: interface > name: nic1 > mtu: {{ ctlplane_mtu }} > use_dhcp: false > addresses: > - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }} > routes: {{ ctlplane_host_routes }} > - type: ovs_bridge > name: br1 > dns_servers: {{ ctlplane_dns_nameservers }} > domain: {{ dns_search_domains }} > members: > - type: ovs_bond > name: bond1 > mtu: {{ min_viable_mtu }} > ovs_options: {{ bond_interface_ovs_options }} > members: > - type: interface > name: nic3 > mtu: {{ min_viable_mtu }} > primary: true > - type: interface > name: nic4 > mtu: {{ min_viable_mtu }} > - type: vlan > mtu: {{ min_viable_mtu }} > vlan_id: storage_vlan_id > addresses: > - ip_netmask: storage_ip/ storage_cidr > routes: storage_host_routes > - type: vlan > mtu: {{ min_viable_mtu }} > vlan_id: storage_mgmt_vlan_id > addresses: > - ip_netmask: storage_mgmt_ip/storage_mgmt_cidr > routes: storage_mgmt_host_routes > - type: ovs_bridge > name: br2 > dns_servers: {{ ctlplane_dns_nameservers }} > domain: {{ dns_search_domains }} > members: > - type: ovs_bond > name: bond2 > mtu: {{ min_viable_mtu }} > ovs_options: {{ bond_interface_ovs_options }} > members: > - type: interface > name: nic5 > mtu: {{ min_viable_mtu }} > primary: true > - type: interface > name: nic6 > mtu: {{ min_viable_mtu }} > - type: vlan > mtu: {{ min_viable_mtu }} > vlan_id: internal_api_vlan_id > addresses: > - ip_netmask: internal_api_ip/internal_api_cidr > routes: internal_api_host_routes > - type: vlan > mtu: {{ min_viable_mtu }} > vlan_id: tenant_vlan_id > addresses: > - ip_netmask: tenant_ip/tenant_cidr > routes: tenant_host_routes > - type: vlan > mtu: {{ min_viable_mtu }} > vlan_id: external_vlan_id > addresses: > - ip_netmask: external_ip/external_cidr > routes: external_host_routes > Regards Le mar. 24 août 2021 à 18:07, wodel youchi a écrit : > Hi and thanks for the help. > > My network is simple, I have 5 nics per node : > - first nic : provisioning > - second and third nics as bond : storage and storage mgmt > - fourth and fifth nics as bond : tenant, api and external > > > I modified the baremetal_deployment.yaml as you suggested, > >> - name: Controller >> count: 3 >> hostname_format: controller-%index% >> defaults: >> profile: control >> networks: >> - network: external >> subnet: external_subnet >> - network: internal_api >> subnet: internal_api_subnet >> - network: storage >> subnet: storage_subnet >> - network: storage_mgmt >> subnet: storage_mgmt_subnet >> - network: tenant >> subnet: tenant_subnet >> network_config: >> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >> default_route_network: >> - external >> - name: ComputeHCI >> count: 3 >> hostname_format: computehci-%index% >> defaults: >> profile: computeHCI >> networks: >> - network: internal_api >> subnet: internal_api_subnet >> - network: tenant >> subnet: tenant_subnet >> - network: storage >> subnet: storage_subnet >> - network: storage_mgmt >> subnet: storage_mgmt_subnet >> network_config: >> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >> > > > > but still errors, and this time I have nothing to go with > Error : > >> <10.100.4.7> SSH: EXEC ssh -o UserKnownHostsFile=/dev/null -o >> StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPersist=30m -o >> ServerAliveInterval=64 -o ServerAliveCountMax=[55/1822] >> ompression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no >> -o ForwardAgent=yes -o PreferredAuthentications=publickey -T -o >> StrictHostKeyChecking=no -o KbdInteractiveAuthentic >> ation=no -o >> PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey >> -o PasswordAuthentication=no -o 'User="heat-admin"' -o ConnectTimeout=30 -o >> ControlPath=/home/stack/.an >> sible/cp/ca32d1049e 10.100.4.7 '/bin/sh -c '"'"'rm -f -r >> /home/heat-admin/.ansible/tmp/ansible-tmp-1629824478.3189409-228106-213914436967091/ >> > /dev/null 2>&1 && sleep 0'"'"'' >> >> >> >> >> >> >> >> >> *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 | >> FATAL | Render network_config from template | computehci-1 | error={ >> "censored": "the output has been hidden due to the fact that 'no_log: true' >> was specified for this result", "changed": false}2021-08-24 >> 18:01:18.372773 | 52540075-9baf-8232-d4fa-0000000000a0 | TIMING | >> tripleo_network_config : Render network_config from template | computehci-1 >> | 0:00:45.837722 | 0.19s 2021-08-24 18:01:18.373749 | >> 52540075-9baf-8232-d4fa-0000000000a0 | FATAL | Render network_config >> from template | computehci-0 | error={ "censored": "the output has been >> hidden due to the fact that 'no_log: true' was specified for this result", >> "changed": false}* >> 2021-08-24 18:01:18.374225 | 52540075-9baf-8232-d4fa-0000000000a0 | >> TIMING | tripleo_network_config : Render network_config from template | >> computehci-0 | 0:00:45.839181 | 0.20s >> <10.100.4.13> rc=0, stdout and stderr censored due to no log >> <10.100.4.10> rc=0, stdout and stderr censored due to no log >> <10.100.4.23> rc=0, stdout and stderr censored due to no log >> 2021-08-24 18:01:18.385393 | 52540075-9baf-8232-d4fa-0000000000a0 | >> FATAL | Render network_config from template | controller-0 | error={ >> "censored": "the output has been hidden due to the fact that 'no_log: >> true' was specified for this result", >> "changed": false >> } >> 2021-08-24 18:01:18.385962 | 52540075-9baf-8232-d4fa-0000000000a0 | >> TIMING | tripleo_network_config : Render network_config from template | >> controller-0 | 0:00:45.850915 | 0.19s >> 2021-08-24 18:01:18.387075 | 52540075-9baf-8232-d4fa-0000000000a0 | >> FATAL | Render network_config from template | controller-1 | error={ >> >> "censored": "the output has been hidden due to the fact that 'no_log: >> true' was specified for this result", >> >> "changed": false >> } >> 2021-08-24 18:01:18.387597 | 52540075-9baf-8232-d4fa-0000000000a0 | >> TIMING | tripleo_network_config : Render network_config from template | >> controller-1 | 0:00:45.852553 | 0.18s >> 2021-08-24 18:01:18.388389 | 52540075-9baf-8232-d4fa-0000000000a0 | >> FATAL | Render network_config from template | computehci-2 | error={ >> >> "censored": "the output has been hidden due to the fact that 'no_log: >> true' was specified for this result", >> >> "changed": false >> } >> 2021-08-24 18:01:18.388902 | 52540075-9baf-8232-d4fa-0000000000a0 | >> TIMING | tripleo_network_config : Render network_config from template | >> computehci-2 | 0:00:45.853857 | 0.20s >> <10.100.4.7> rc=0, stdout and stderr censored due to no log >> 2021-08-24 18:01:18.399921 | 52540075-9baf-8232-d4fa-0000000000a0 | >> FATAL | Render network_config from template | controller-2 | error={ >> "censored": "the output has been hidden due to the fact that 'no_log: >> true' was specified for this result", >> "changed": false >> > > Any ideas? > > > Le mar. 24 août 2021 à 15:28, Sandeep Yadav a > écrit : > >> >> Could you please change subnets names to be the same for your >> Controller and ComputeHCI role say internal_api. >> >> typo: Could you please change subnets names to be the same for your >> Controller and ComputeHCI role say internal_api_subnet. >> >> >> On Tue, Aug 24, 2021 at 7:48 PM Sandeep Yadav >> wrote: >> >>> Hello, >>> >>> To me it looks like the example shared in the documentation[1] is for >>> leaf-spine arch. >>> >>> Currently, You have a different set of subnets under your Controller and >>> ComputeHCI role. >>> >>> Taking internal_api reference from your baremetal_deployment.yaml >>> ~~~ >>> - network: internal_api >>> subnet: internal_api_subnet01 >>> >>> . >>> . >>> - network: internal_api >>> subnet: internal_api_subnet02 >>>> >>> ~~~ >>> >>> If leaf-spine arch is not what you want, Could you please change subnets >>> names to be the same for your Controller and ComputeHCI role say >>> internal_api. >>> >>> Also, I am assuming you are following documentation [2], For "openstack >>> overcloud network provision" command also make sure your networks/subnets >>> names in network_data.yaml (sample ref[3]) are consistent with what you as >>> wish to do in baremetal_deployment.yaml >>> >>> [1] >>> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml >>> [2] >>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/network_v2.html#provision-baremetal-instances >>> [3] >>> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/default-network-isolation.yaml >>> >>> On Tue, Aug 24, 2021 at 5:20 PM wodel youchi >>> wrote: >>> >>>> Hi again, >>>> >>>> Here is the error I am getting when trying to generate the *overcloud-baremetal-deployed.yaml >>>> *file : >>>> CMD : openstack overcloud node provision --stack overcloud >>>> --network-config --output ~/templates/overcloud-baremetal-deployed.yaml >>>> ~/templates/baremetal_deployment.yaml >>>> >>>> Error : >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *The full traceback is: >>>>> >>>>> File >>>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>>> line 601, in run_module >>>>> File >>>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>>> line 494, in manage_instances_ports File >>>>> "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run >>>>> result = self.fn(*self.args, **self.kwargs) File >>>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>>> line 385, in _provision_ports File >>>>> "/tmp/ansible_tripleo_overcloud_network_ports_payload_xszb9ooz/ansible_tripleo_overcloud_network_ports_payload.zip/ansible/modules/tripleo_overcloud_network_ports.py", >>>>> line 319, in generate_port_defs* >>>>> ], >>>>> "template": >>>>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>>>> }, >>>>> "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" >>>>> }, >>>>> { >>>>> >>>>> [215/1899] >>>>> "network": "tenant", >>>>> "subnet": "tenant_subnet01" >>>>> }, >>>>> { >>>>> "network": "ctlplane", >>>>> "vif": true >>>>> } >>>>> ], >>>>> "nics": [ >>>>> { >>>>> "network": "ctlplane" >>>>> } >>>>> ], >>>>> "ssh_public_keys": "ssh-rsa >>>>> AAAAB3NzaC1yc2EAAAADAQABAAAAgQDdFv9qwUs3x6egY5Xke3gh2O8CnXTJ2h2jRpWYEFzL1fyZrMKykMBUEfbkQGYzONsE29/BpS265Df4RgZB3eHx4KWcaskSwjl >>>>> DaUzxP0ZsSl2MzxtDIqE3UTrsmivNGx0ungcTorOc96V9daqU/Vu2HU8J+YEA6+OjddPX1ngz/w== >>>>> root at undercloud.umaitek.dz ", >>>>> "user_name": "heat-admin" >>>>> }, >>>>> { >>>>> "capabilities": { >>>>> "profile": "computeHCI" >>>>> }, >>>>> "config_drive": { >>>>> "meta_data": { >>>>> "instance-type": "ComputeHCI" >>>>> } >>>>> }, >>>>> "hostname": "computehci-0", >>>>> "image": { >>>>> "href": >>>>> "file:///var/lib/ironic/images/overcloud-full.raw", >>>>> "kernel": >>>>> "file:///var/lib/ironic/images/overcloud-full.vmlinuz", >>>>> "ramdisk": >>>>> "file:///var/lib/ironic/images/overcloud-full.initrd" >>>>> }, >>>>> "network_config": { >>>>> "template": >>>>> "/home/stack/templates/nic-configs/bonds_vlans.j2" >>>>> }, >>>>> "networks": [ >>>>> "network": "internal_api", >>>>> "subnet": "internal_api_subnet02" >>>>> }, >>>>> { >>>>> "network": "tenant", >>>>> "subnet": "tenant_subnet02" >>>>> }, >>>>> { >>>>> "network": "storage", >>>>> "subnet": "storage_subnet02" >>>>> }, >>>>> { >>>>> "network": "storage_mgmt", >>>>> "subnet": "storage_mgmt_subnet02" >>>>> 2021-08-24 10:21:18.492374 | >>>>> 52540075-9baf-0191-8598-000000000019 | FATAL | Provision instance >>>>> network ports | localhost | error={ >>>>> "changed": true, >>>>> "error": "'internal_api_subnet02'", >>>>> "invocation": { >>>>> "module_args": { >>>>> "api_timeout": null, >>>>> "auth": null, >>>>> "auth_type": null, >>>>> "availability_zone": null, >>>>> "ca_cert": null, >>>>> "client_cert": null, >>>>> "client_key": null, >>>>> "concurrency": 2, >>>>> "hostname_role_map": { >>>>> "computehci-0": "ComputeHCI", >>>>> "controller-0": "Controller" >>>>> }, >>>>> ... >>>>> ... >>>>> ... >>>>> "provisioned_instances": [ >>>>> >>>>> [38/1899] >>>>> { >>>>> "hostname": "controller-0", >>>>> "id": "1dff400f-0dd1-4eb0-b4c1-84397d387a4a", >>>>> "name": "controller0" >>>>> }, >>>>> { >>>>> "hostname": "computehci-0", >>>>> "id": "3d6c399f-53b7-472b-b784-67193a485e43", >>>>> "name": "computeHCI0" >>>>> } >>>>> ], >>>>> "region_name": null, >>>>> "stack_name": "overcloud", >>>>> "state": "present", >>>>> "timeout": 180, >>>>> "validate_certs": null, >>>>> "wait": true >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> * }, "msg": "Error managing network ports >>>>> 'internal_api_subnet02'", "node_port_map": {}, "success": false}* >>>>> 2021-08-24 10:21:18.494473 | 52540075-9baf-0191-8598-000000000019 | >>>>> TIMING | Provision instance network ports | localhost | 0:04:58.315416 | >>>>> 3.72s >>>>> >>>>> NO MORE HOSTS LEFT >>>>> ************************************************************* >>>>> >>>>> PLAY RECAP >>>>> ********************************************************************* >>>>> localhost : ok=10 changed=3 unreachable=0 >>>>> failed=1 skipped=5 rescued=0 ignored=0 >>>>> 2021-08-24 10:21:18.498948 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.499338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >>>>> Tasks: 16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.499755 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed >>>>> Time: 0:04:58.320717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.500105 | UUID | >>>>> Info | Host | Task Name | Run Time >>>>> 2021-08-24 10:21:18.500449 | 52540075-9baf-0191-8598-000000000017 | >>>>> SUMMARY | localhost | Provision instances | 285.25s >>>>> 2021-08-24 10:21:18.500868 | 52540075-9baf-0191-8598-000000000014 | >>>>> SUMMARY | localhost | Reserve instances | 6.08s >>>>> 2021-08-24 10:21:18.501228 | 52540075-9baf-0191-8598-000000000019 | >>>>> SUMMARY | localhost | Provision instance network ports | 3.72s >>>>> 2021-08-24 10:21:18.501588 | 52540075-9baf-0191-8598-000000000013 | >>>>> SUMMARY | localhost | Find existing instances | 1.52s >>>>> 2021-08-24 10:21:18.501944 | 52540075-9baf-0191-8598-000000000012 | >>>>> SUMMARY | localhost | Expand roles | 0.92s >>>>> 2021-08-24 10:21:18.502281 | 52540075-9baf-0191-8598-00000000000c | >>>>> SUMMARY | localhost | stat overcloud-full.raw | 0.26s >>>>> 2021-08-24 10:21:18.502706 | 52540075-9baf-0191-8598-00000000000d | >>>>> SUMMARY | localhost | stat overcloud-full.initrd | 0.19s >>>>> 2021-08-24 10:21:18.503053 | 52540075-9baf-0191-8598-00000000000e | >>>>> SUMMARY | localhost | Set file based default image | 0.04s >>>>> 2021-08-24 10:21:18.503419 | 52540075-9baf-0191-8598-000000000018 | >>>>> SUMMARY | localhost | Metalsmith log for provision instances | 0.04s >>>>> 2021-08-24 10:21:18.503806 | 52540075-9baf-0191-8598-000000000016 | >>>>> SUMMARY | localhost | Set concurrency fact | 0.04s >>>>> 2021-08-24 10:21:18.504139 | 52540075-9baf-0191-8598-000000000015 | >>>>> SUMMARY | localhost | Metalsmith log for reserve instances | 0.04s >>>>> 2021-08-24 10:21:18.504469 | 52540075-9baf-0191-8598-00000000000f | >>>>> SUMMARY | localhost | Set whole-disk file based default image | 0.03s >>>>> 2021-08-24 10:21:18.504849 | 52540075-9baf-0191-8598-000000000010 | >>>>> SUMMARY | localhost | Set glance based default image | 0.03s >>>>> 2021-08-24 10:21:18.505246 | 52540075-9baf-0191-8598-000000000009 | >>>>> SUMMARY | localhost | fail | 0.03s >>>>> 2021-08-24 10:21:18.505627 | 52540075-9baf-0191-8598-000000000008 | >>>>> SUMMARY | localhost | fail | 0.03s >>>>> 2021-08-24 10:21:18.505987 | 52540075-9baf-0191-8598-00000000000a | >>>>> SUMMARY | localhost | fail | 0.02s >>>>> 2021-08-24 10:21:18.506315 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >>>>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.506693 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State >>>>> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.507032 | ~~~~~~~~~~~~~~~~~~ Number of nodes which >>>>> did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >>>>> 2021-08-24 10:21:18.507351 | The following node(s) had failures: >>>>> localhost >>>>> 2021-08-24 10:21:18.507720 | >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Temporary directory [ /tmp/tripleob9lxg9vi ] cleaned up >>>>> Ansible execution failed. playbook: >>>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>>> Status: failed, Return Code: 2 >>>>> Temporary directory [ /tmp/tripleoyso22wsn ] cleaned up >>>>> Exception occured while running the command >>>>> Traceback (most recent call last): >>>>> File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", >>>>> line 34, in run >>>>> super(Command, self).run(parsed_args) >>>>> File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", >>>>> line 39, in run >>>>> return super(Command, self).run(parsed_args) >>>>> File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, >>>>> in run >>>>> return_code = self.take_action(parsed_args) or 0 >>>>> File >>>>> "/usr/lib/python3.6/site-packages/tripleoclient/v2/overcloud_node.py", line >>>>> 323, in take_action >>>>> extra_vars=extra_vars, >>>>> File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line >>>>> 724, in run_ansible_playbook >>>>> raise RuntimeError(err_msg) >>>>> RuntimeError: Ansible execution failed. playbook: >>>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>>> Status: failed, Return Code: 2 >>>>> Ansible execution failed. playbook: >>>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>>> Status: failed, Return Code: 2 >>>>> clean_up ProvisionNode: Ansible execution failed. playbook: >>>>> /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-provision.yaml, Run >>>>> Status: failed, Return Code: 2 >>>>> END return value: 1 >>>>> >>>> >>>> Here is my baremetal_deployment.yaml file : >>>> >>>>> - name: Controller >>>>> count: 1 >>>>> hostname_format: controller-%index% >>>>> 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: /home/stack/templates/nic-configs/bonds_vlans.j2 >>>>> default_route_network: >>>>> - external >>>>> - name: ComputeHCI >>>>> count: 1 >>>>> hostname_format: computehci-%index% >>>>> defaults: >>>>> profile: computeHCI >>>>> networks: >>>>> - network: internal_api >>>>> subnet: internal_api_subnet02 >>>>> - network: tenant >>>>> subnet: tenant_subnet02 >>>>> - network: storage >>>>> subnet: storage_subnet02 >>>>> - network: storage_mgmt >>>>> subnet: storage_mgmt_subnet02 >>>>> network_config: >>>>> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >>>>> >>>> >>>> >>>> If someone can help me and point me where to look. >>>> Any help will be appreciated. >>>> >>>> Regards. >>>> >>>> Le lun. 23 août 2021 à 12:48, wodel youchi a >>>> écrit : >>>> >>>>> 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 wodel.youchi at gmail.com Tue Aug 24 21:25:59 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 24 Aug 2021 22:25:59 +0100 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hello, After digging after grafana, it seems it needed to download something from the internet, and i didn't really configure a proper gateway on the external network. So I started by configuring a proper gateway and I tested it with the half deployed nodes, the I redid the deployment, and again I got this error : 2021-08-24 21:29:29.616805 | 525400e8-92c8-d397-6f7e-000000006133 | > FATAL | Clean up legacy Cinder keystone catalog entries | undercloud | > error={"changed": false, "module_stderr": "Fa > iled to discover available identity versions when contacting > http://10.0.2.40:5000. Attempting to parse version from URL.\nTraceback > (most recent call last):\n File \"/usr/lib/python3.6/si > te-packages/urllib3/connection.py\", line 162, in _new_conn\n > (self._dns_host, self.port), self.timeout, **extra_kw)\n File > \"/usr/lib/python3.6/site-packages/urllib3/util/connection.py > \", line 80, in create_connection\n raise err\n File > \"/usr/lib/python3.6/site-packages/urllib3/util/connection.py\", line 70, > in create_connection\n sock.connect(sa)\nTimeoutError: > [Errno 110] Connection timed out\n\nDuring handling of the above > exception, another exception occurred:\n\nTraceback (most recent call > last):\n File \"/usr/lib/python3.6/site-packages/urll > ib3/connectionpool.py\", line 600, in urlopen\n chunked=chunked)\n > File \"/usr/lib/python3.6/site-packages/urllib3/connectionpool.py\", line > 354, in _make_request\n conn.request(meth > od, url, **httplib_request_kw)\n File > \"/usr/lib64/python3.6/http/client.py\", line 1269, in request\n > self._send_request(method, url, body, headers, encode_chunked)\n File > \"/usr/lib6 > 4/python3.6/http/client.py\", line 1315, in _send_request\n > self.endheaders(body, encode_chunked=encode_chunked)\n File > \"/usr/lib64/python3.6/http/client.py\", line 1264, in endheaders > \n self._send_output(message_body, encode_chunked=encode_chunked)\n > File \"/usr/lib64/python3.6/http/client.py\", line 1040, in _send_output\n > self.send(msg)\n File \"/usr/lib64/pyt > hon3.6/http/client.py\", line 978, in send\n self.connect()\n File > \"/usr/lib/python3.6/site-packages/urllib3/connection.py\", line 184, in > connect\n conn = self._new_conn()\n File > \"/usr/lib/python3.6/site-packages/urllib3/connection.py\", line 171, in > _new_conn\n self, \"Failed to establish a new connection: %s\" % > e)\nurllib3.exceptions.NewConnectionError: ib3.connection.HTTPConnection object at 0x7f96f7b10cc0>: Failed to > establish a new connection: [Errno 110] Connection timed out\n\nDuring > handling of the above exception, another exception > occurred:\n\nTraceback (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/requests/adapters.py\", line 449, in > send\n timeout=timeout\n File \"/usr/lib/python3.6/site-p > ackages/urllib3/connectionpool.py\", line 638, in urlopen\n > _stacktrace=sys.exc_info()[2])\n File > \"/usr/lib/python3.6/site-packages/urllib3/util/retry.py\", line 399, in > increment\n > raise MaxRetryError(_pool, url, error or > ResponseError(cause))\nurllib3.exceptions.MaxRetryError: > HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries exceeded with > url: / (Caused > by NewConnectionError(' 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno 110] > Connection timed out',))\n\nDuring handling of the ab$ > ve exception, another exception occurred:\n\nTraceback (most recent call > last):\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 997, in > _send_request\n resp $ > self.session.request(method, url, **kwargs)\n File > \"/usr/lib/python3.6/site-packages/requests/sessions.py\", line 533, in > request\n resp = self.send(prep, **send_kwargs)\n File \"/u$ > r/lib/python3.6/site-packages/requests/sessions.py\", line 646, in send\n > r = adapter.send(request, **kwargs)\n File > \"/usr/lib/python3.6/site-packages/requests/adapters.py\", line 516$ > in send\n raise ConnectionError(e, > request=request)\nrequests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries exceeded with > url: / (Caused by N$wConnectionError(' object at 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno > 110] Connection timed out',))\n\nDuring handling of the above e$ > ception, another exception occurred:\n\nTraceback (most recent call > last):\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", > line 138, in _do_create_plug$ > n\n authenticated=False)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/base.py\", line > 610, in get_discovery\n authenticated=authenticated)\n File > \"/usr/lib/pyt$ > on3.6/site-packages/keystoneauth1/discover.py\", line 1442, in > get_discovery\n disc = Discover(session, url, > authenticated=authenticated)\n File > \"/usr/lib/python3.6/site-packages/keys$ > oneauth1/discover.py\", line 526, in __init__\n > authenticated=authenticated)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/discover.py\", line 101, > in get_version_data\n r$ > sp = session.get(url, headers=headers, authenticated=authenticated)\n > File \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line > 1116, in get\n return self.request(url, '$ > ET', **kwargs)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 906, in > request\n resp = send(**kwargs)\n File > \"/usr/lib/python3.6/site-packages/keystoneaut$ > 1/session.py\", line 1013, in _send_request\n raise > exceptions.ConnectFailure(msg)\nkeystoneauth1.exceptions.connection.ConnectFailure: > Unable to establish connection to http://10.0.2.4$ > :5000: HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries > exceeded with url: / (Caused by > NewConnectionError(' 0x7f96f7b10cc0>: Failed > to establish a new connection: [Errno 110] Connection timed > out',))\n\nDuring handling of the above exception, another exception > occurred:\n\nTraceback (most recent call last):\n File \"<$ > tdin>\", line 102, in \n File \"\", line 94, in > _ansiballz_main\n File \"\", line 40, in invoke_module\n File > \"/usr/lib64/python3.6/runpy.py\", line 205, in run_m$ > dule\n return _run_module_code(code, init_globals, run_name, > mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in > _run_module_code\n mod_name, mod_spec, pkg_name, script_$ > ame)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n > exec(code, run_globals)\n File > \"/tmp/ansible_os_keystone_service_payload_wcyk6h37/ansible_os_keystone_service_p$ > yload.zip/ansible/modules/cloud/openstack/os_keystone_service.py\", line > 194, in \n File > \"/tmp/ansible_os_keystone_service_payload_wcyk6h37/ansible_os_keystone_service_payload.zi$ > /ansible/modules/cloud/openstack/os_keystone_service.py\", line 153, in > main\n File > \"/usr/lib/python3.6/site-packages/openstack/cloud/_identity.py\", line > 510, in search_services\n se$ > vices = self.list_services()\n File > \"/usr/lib/python3.6/site-packages/openstack/cloud/_identity.py\", line > 485, in list_services\n if self._is_client_version('identity', 2):\n > File \$ > /usr/lib/python3.6/site-packages/openstack/cloud/openstackcloud.py\", line > 459, in _is_client_version\n client = getattr(self, client_name)\n File > \"/usr/lib/python3.6/site-packages/op$ > nstack/cloud/_identity.py\", line 32, in _identity_client\n 'identity', > min_version=2, max_version='3.latest')\n File > \"/usr/lib/python3.6/site-packages/openstack/cloud/openstackcloud.$ > y\", line 406, in _get_versioned_client\n if adapter.get_endpoint():\n > File \"/usr/lib/python3.6/site-packages/keystoneauth1/adapter.py\", line > 282, in get_endpoint\n return self.se$ > sion.get_endpoint(auth or self.auth, **kwargs)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 1218, > in get_endpoint\n return auth.get_endpoint(self, **kwarg$ > )\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/base.py\", line > 380, in get_endpoint\n allow_version_hack=allow_version_hack, > **kwargs)\n File \"/usr/lib/python3.6/$ > ite-packages/keystoneauth1/identity/base.py\", line 271, in > get_endpoint_data\n service_catalog = > self.get_access(session).service_catalog\n File > \"/usr/lib/python3.6/site-packages/key$ > toneauth1/identity/base.py\", line 134, in get_access\n self.auth_ref = > self.get_auth_ref(session)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", > l$ > ne 206, in get_auth_ref\n self._plugin = > self._do_create_plugin(session)\n File > \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", > line 161, in _do_create_plu$ > in\n 'auth_url is correct. %s' % > e)\nkeystoneauth1.exceptions.discovery.DiscoveryFailure: Could not find > versioned identity endpoints when attempting to authenticate. Please check > that $our auth_url is correct. > > *Unable to establish connection to http://10.0.2.40:5000 > : HTTPConnectionPool(host='10.0.2.40', port=5000): > Max retries exceeded with url: / (Caused by > NewConnectionError(' 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno 110] > Connection timed out',))\n", "module_stdout": "", "msg": "MODULE > FAILURE\nSee stdout/stderr for the exact error", "rc": 1} * > > > 2021-08-24 21:29:29.617697 | 525400e8-92c8-d397-6f7e-000000006133 | > TIMING | Clean up legacy Cinder keystone catalog entries | undercloud | > 1:07:40.666419 | 130.85s > > > > PLAY RECAP > ********************************************************************* > > > overcloud-computehci-0 : ok=260 changed=145 unreachable=0 > failed=0 skipped=140 rescued=0 ignored=0 > > overcloud-computehci-1 : ok=258 changed=145 unreachable=0 > failed=0 skipped=140 rescued=0 ignored=0 > > overcloud-computehci-2 : ok=255 changed=145 unreachable=0 > failed=0 skipped=140 rescued=0 ignored=0 > > overcloud-controller-0 : ok=295 changed=181 unreachable=0 > failed=0 skipped=151 rescued=0 ignored=0 > > overcloud-controller-1 : ok=289 changed=177 unreachable=0 > failed=0 skipped=152 rescued=0 ignored=0 > > overcloud-controller-2 : ok=288 changed=177 unreachable=0 > failed=0 skipped=152 rescued=0 ignored=0 > > undercloud : ok=105 changed=21 unreachable=0 > failed=1 skipped=45 rescued=0 ignored=0 > > > > > 2021-08-24 21:29:29.730778 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary > Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2021-08-24 21:29:29.731007 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Tasks: > 1723 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2021-08-24 21:29:29.731098 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: > 1:07:40.779840 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2021-08-24 21:29:29.731172 | UUID | > Info | Host | Task Name | Run Time > > 2021-08-24 21:29:29.731251 | 525400e8-92c8-d397-6f7e-000000003b9a | > SUMMARY | undercloud | Run tripleo-container-image-prepare logged to: > /var/log/tripleo-container-image-prepare.log | 1762.93s > > > > 2021-08-24 21:29:29.731349 | 525400e8-92c8-d397-6f7e-0000000057aa | > SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ansible | > 990.24s > 2021-08-24 21:29:29.731433 | 525400e8-92c8-d397-6f7e-000000005951 | > SUMMARY | overcloud-controller-0 | tripleo_ha_wrapper : Run init bundle > puppet on the host for haproxy | 133.22s > 2021-08-24 21:29:29.731503 | 525400e8-92c8-d397-6f7e-000000006133 | > SUMMARY | undercloud | Clean up legacy Cinder keystone catalog entries | > 130.85s > 2021-08-24 21:29:29.731569 | 525400e8-92c8-d397-6f7e-000000006012 | > SUMMARY | overcloud-controller-0 | Wait for containers to start for step 3 > using paunch | 103.45s > 2021-08-24 21:29:29.731643 | 525400e8-92c8-d397-6f7e-000000004337 | > SUMMARY | overcloud-computehci-0 | Pre-fetch all the containers | 94.00s > > 2021-08-24 21:29:29.731729 | 525400e8-92c8-d397-6f7e-000000004378 | > SUMMARY | overcloud-computehci-2 | Pre-fetch all the containers | 92.64s > > 2021-08-24 21:29:29.731795 | 525400e8-92c8-d397-6f7e-000000004337 | > SUMMARY | overcloud-computehci-1 | Pre-fetch all the containers | 86.38s > > 2021-08-24 21:29:29.731867 | 525400e8-92c8-d397-6f7e-000000004d68 | > SUMMARY | overcloud-controller-0 | Wait for container-puppet tasks > (generate config) to finish | 84.13s > 2021-08-24 21:29:29.731946 | 525400e8-92c8-d397-6f7e-000000004d99 | > SUMMARY | overcloud-controller-2 | Wait for container-puppet tasks > (generate config) to finish | 80.76s > 2021-08-24 21:29:29.732012 | 525400e8-92c8-d397-6f7e-00000000427c | > SUMMARY | overcloud-controller-1 | Pre-fetch all the containers | 80.21s > > 2021-08-24 21:29:29.732073 | 525400e8-92c8-d397-6f7e-00000000427c | > SUMMARY | overcloud-controller-0 | Pre-fetch all the containers | 77.03s > > 2021-08-24 21:29:29.732138 | 525400e8-92c8-d397-6f7e-0000000042f5 | > SUMMARY | overcloud-controller-2 | Pre-fetch all the containers | 76.32s > > 2021-08-24 21:29:29.732202 | 525400e8-92c8-d397-6f7e-000000004dd3 | > SUMMARY | overcloud-controller-1 | Wait for container-puppet tasks > (generate config) to finish | 74.36s > 2021-08-24 21:29:29.732266 | 525400e8-92c8-d397-6f7e-000000005da7 | > SUMMARY | overcloud-controller-0 | tripleo_ha_wrapper : Run init bundle > puppet on the host for ovn_dbs | 68.39s > 2021-08-24 21:29:29.732329 | 525400e8-92c8-d397-6f7e-000000005ce2 | > SUMMARY | overcloud-controller-0 | Wait for containers to start for step 2 > using paunch | 64.55s > 2021-08-24 21:29:29.732398 | 525400e8-92c8-d397-6f7e-000000004b97 | > SUMMARY | overcloud-controller-2 | Wait for puppet host configuration to > finish | 58.13s > 2021-08-24 21:29:29.732463 | 525400e8-92c8-d397-6f7e-000000004c1a | > SUMMARY | overcloud-controller-1 | Wait for puppet host configuration to > finish | 58.11s > 2021-08-24 21:29:29.732526 | 525400e8-92c8-d397-6f7e-000000005bd3 | > SUMMARY | overcloud-controller-1 | Wait for containers to start for step 2 > using paunch | 58.09s > 2021-08-24 21:29:29.732589 | 525400e8-92c8-d397-6f7e-000000005b9b | > SUMMARY | overcloud-controller-2 | Wait for containers to start for step 2 > using paunch | 58.09s > Thank you again for your assistance. Regards. Le mar. 24 août 2021 à 08:59, wodel youchi a écrit : > Hi, and thanks for your help > > As for Ceph, here is container prepare > parameter_defaults: > ContainerImagePrepare: > - push_destination: true > set: > ceph_alertmanager_image: alertmanager > ceph_alertmanager_namespace: quay.ceph.io/prometheus > ceph_alertmanager_tag: v0.16.2 > ceph_grafana_image: grafana > ceph_grafana_namespace: quay.ceph.io/app-sre > *ceph_grafana_tag: 5.4.3* > ceph_image: daemon > ceph_namespace: quay.ceph.io/ceph-ci > ceph_node_exporter_image: node-exporter > ceph_node_exporter_namespace: quay.ceph.io/prometheus > ceph_node_exporter_tag: v0.17.0 > ceph_prometheus_image: prometheus > ceph_prometheus_namespace: quay.ceph.io/prometheus > ceph_prometheus_tag: v2.7.2 > *ceph_tag: v4.0.19-stable-4.0-nautilus-centos-7-x86_64* > name_prefix: centos-binary- > name_suffix: '' > namespace: quay.io/tripleotraincentos8 > neutron_driver: ovn > rhel_containers: false > tag: current-tripleo > tag_from_label: rdo_version > > And yes, the 10.200.7.0/24 network is my storage network > Here is a snippet from my network_data.yaml > > - name: Storage > vip: true > vlan: 1107 > name_lower: storage > ip_subnet: '10.200.7.0/24' > allocation_pools: [{'start': '10.200.7.150', 'end': '10.200.7.169'}] > > I will look into the grafana service to see why it's not booting and get > back to you. > > Regards. > > Le lun. 23 août 2021 à 17:28, Francesco Pantano a > écrit : > >> Hello, >> thanks John for your reply here. >> A few more comments inline: >> >> On Mon, Aug 23, 2021 at 6:16 PM John Fulton wrote: >> >>> On Mon, Aug 23, 2021 at 10:52 AM wodel youchi >>> wrote: >>> > >>> > Hi, >>> > >>> > I redid the undercloud deployment for the Train version for now. And I >>> verified the download URL for the images. >>> > My overcloud deployment has moved forward but I still get errors. >>> > >>> > This is what I got this time : >>> >> >>> >> "TASK [ceph-grafana : wait for grafana to start] >>> ********************************", >>> >> "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) >>> 0:12:59.319 ********* ", >>> >> "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": >>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>> >> 0.7.151:3100\"}", >>> >> "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": >>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>> >> 0.7.155:3100\"}", >>> >> "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": >>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>> >> 0.7.165:3100\"}", >>> >>> I'm not certain of the ceph-ansible version you're using but it should >>> be a version 4 with train. ceph-ansible should already be installed on >>> your undercloud judging by this error and in the latest version 4 this >>> task is where it failed: >>> >>> >>> https://github.com/ceph/ceph-ansible/blob/v4.0.64/roles/ceph-grafana/tasks/configure_grafana.yml#L112-L115 >>> >>> You can check the status of this service on your three controllers and >>> then debug it directly. >> >> As John pointed out, ceph-ansible is able to configure, render and start >> the associated >> systemd unit for all the ceph monitoring stack components (node-exported, >> prometheus, alertmanager and >> grafana). >> You can ssh to your controllers, and check the systemd unit associated, >> checking the journal to see why >> they failed to start (I saw there's a timeout waiting for the container >> to start). >> A potential plan, in this case, could be: >> >> 1. check the systemd unit (I guess you can start with grafana which is >> the failed service) >> 2. look at the journal logs (feel free to attach here the relevant part >> of the output) >> 3. double check the network where the service is bound (can you attach >> the /var/lib/mistral//ceph-ansible/group_vars/all.yaml) >> * The grafana process should be run on the storage network, but I see >> a "Timeout when waiting for 10.200.7.165:3100": is that network the >> right one? >> >>> >> >> >>> John >>> >>> >> "RUNNING HANDLER [ceph-prometheus : service handler] >>> ****************************", >>> >> "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) >>> 0:18:00.087 ********* ", >>> >> "PLAY RECAP >>> *********************************************************************", >>> >> "overcloud-computehci-0 : ok=224 changed=23 >>> unreachable=0 failed=0 skipped=415 rescued=0 ignored=0 ", >>> >> "overcloud-computehci-1 : ok=199 changed=18 >>> unreachable=0 failed=0 skipped=392 rescued=0 ignored=0 ", >>> >> "overcloud-computehci-2 : ok=212 changed=23 >>> unreachable=0 failed=0 skipped=390 rescued=0 ignored=0 ", >>> >> "overcloud-controller-0 : ok=370 changed=52 >>> unreachable=0 failed=1 skipped=539 rescued=0 ignored=0 ", >>> >> "overcloud-controller-1 : ok=308 changed=43 >>> unreachable=0 failed=1 skipped=495 rescued=0 ignored=0 ", >>> >> "overcloud-controller-2 : ok=317 changed=45 >>> unreachable=0 failed=1 skipped=493 rescued=0 ignored=0 ", >>> >> >>> >> "INSTALLER STATUS >>> ***************************************************************", >>> >> "Install Ceph Monitor : Complete (0:00:52)", >>> >> "Install Ceph Manager : Complete (0:05:49)", >>> >> "Install Ceph OSD : Complete (0:02:28)", >>> >> "Install Ceph RGW : Complete (0:00:27)", >>> >> "Install Ceph Client : Complete (0:00:33)", >>> >> "Install Ceph Grafana : In Progress (0:05:54)", >>> >> "\tThis phase can be restarted by running: >>> roles/ceph-grafana/tasks/main.yml", >>> >> "Install Ceph Node Exporter : Complete (0:00:28)", >>> >> "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) >>> 0:18:00.094 ********* ", >>> >> >>> "=============================================================================== >>> ", >>> >> "ceph-grafana : wait for grafana to start >>> ------------------------------ 300.77s", >>> >> "ceph-facts : get ceph current status >>> ---------------------------------- 300.27s", >>> >> "ceph-container-common : pulling >>> udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 >>> >> image -- 19.04s", >>> >> "ceph-mon : waiting for the monitor(s) to form the quorum... >>> ------------ 12.83s", >>> >> "ceph-osd : use ceph-volume lvm batch to create bluestore osds >>> ---------- 12.13s", >>> >> "ceph-osd : wait for all osd to be up >>> ----------------------------------- 11.88s", >>> >> "ceph-osd : set pg_autoscale_mode value on pool(s) >>> ---------------------- 11.00s", >>> >> "ceph-osd : create openstack pool(s) >>> ------------------------------------ 10.80s", >>> >> "ceph-grafana : make sure grafana is down >>> ------------------------------- 10.66s", >>> >> "ceph-osd : customize pool crush_rule >>> ----------------------------------- 10.15s", >>> >> "ceph-osd : customize pool size >>> ----------------------------------------- 10.15s", >>> >> "ceph-osd : customize pool min_size >>> ------------------------------------- 10.14s", >>> >> "ceph-osd : assign application to pool(s) >>> ------------------------------- 10.13s", >>> >> "ceph-osd : list existing pool(s) >>> ---------------------------------------- 8.59s", >>> >> >>> >> "ceph-mon : fetch ceph initial keys >>> -------------------------------------- 7.01s", >>> >> "ceph-container-common : get ceph version >>> -------------------------------- 6.75s", >>> >> "ceph-prometheus : start prometheus services >>> ----------------------------- 6.67s", >>> >> "ceph-mgr : wait for all mgr to be up >>> ------------------------------------ 6.66s", >>> >> "ceph-grafana : start the grafana-server service >>> ------------------------- 6.33s", >>> >> "ceph-mgr : create ceph mgr keyring(s) on a mon node >>> --------------------- 6.26s" >>> >> ], >>> >> "failed_when_result": true >>> >> } >>> >> 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | >>> TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ >>> >> in case of failure | undercloud | 0:37:30.226345 | 0.25s >>> >> >>> >> PLAY RECAP >>> ********************************************************************* >>> >> overcloud-computehci-0 : ok=213 changed=117 unreachable=0 >>> failed=0 skipped=120 rescued=0 ignored=0 >>> >> overcloud-computehci-1 : ok=207 changed=117 unreachable=0 >>> failed=0 skipped=120 rescued=0 ignored=0 >>> >> overcloud-computehci-2 : ok=207 changed=117 unreachable=0 >>> failed=0 skipped=120 rescued=0 ignored=0 >>> >> overcloud-controller-0 : ok=237 changed=145 unreachable=0 >>> failed=0 skipped=128 rescued=0 ignored=0 >>> >> overcloud-controller-1 : ok=232 changed=145 unreachable=0 >>> failed=0 skipped=128 rescued=0 ignored=0 >>> >> overcloud-controller-2 : ok=232 changed=145 unreachable=0 >>> failed=0 skipped=128 rescued=0 ignored=0 >>> >> undercloud : ok=100 changed=18 unreachable=0 >>> failed=1 skipped=37 rescued=0 ignored=0 >>> >> >>> >> 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >>> Tasks: 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed >>> Time: 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.560490 | UUID | >>> Info | Host | Task Name | Run Time >>> >> 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | >>> SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans >>> >> ible | 1082.71s >>> >> 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | >>> SUMMARY | overcloud-controller-1 | Wait for container-puppet t >>> >> asks (generate config) to finish | 356.02s >>> >> 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | >>> SUMMARY | overcloud-controller-0 | Wait for container-puppet t >>> >> asks (generate config) to finish | 355.74s >>> >> 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | >>> SUMMARY | overcloud-controller-2 | Wait for container-puppet t >>> >> asks (generate config) to finish | 355.68s >>> >> 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | >>> SUMMARY | undercloud | Run tripleo-container-image-prepare log >>> >> ged to: /var/log/tripleo-container-image-prepare.log | 143.03s >>> >> 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | >>> SUMMARY | overcloud-controller-0 | Wait for puppet host config >>> >> uration to finish | 125.36s >>> >> 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | >>> SUMMARY | overcloud-controller-2 | Wait for puppet host config >>> >> uration to finish | 125.33s >>> >> 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | >>> SUMMARY | overcloud-controller-1 | Wait for puppet host config >>> >> uration to finish | 125.25s >>> >> 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | >>> SUMMARY | overcloud-controller-2 | Run puppet on the host to a >>> >> pply IPtables rules | 108.08s >>> >> 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | >>> SUMMARY | overcloud-controller-0 | Run puppet on the host to a >>> >> pply IPtables rules | 107.34s >>> >> 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | >>> SUMMARY | overcloud-computehci-2 | Wait for container-puppet t >>> >> asks (generate config) to finish | 96.56s >>> >> 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | >>> SUMMARY | overcloud-computehci-0 | Wait for container-puppet t >>> >> asks (generate config) to finish | 96.38s >>> >> 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | >>> SUMMARY | overcloud-computehci-1 | Wait for container-puppet t >>> >> asks (generate config) to finish | 93.41s >>> >> 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | >>> SUMMARY | overcloud-computehci-0 | Pre-fetch all the container >>> >> s | 92.70s >>> >> 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | >>> SUMMARY | overcloud-computehci-2 | Pre-fetch all the container >>> >> s | 91.90s >>> >> 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | >>> SUMMARY | overcloud-computehci-1 | Pre-fetch all the container >>> >> s | 91.88s >>> >> 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | >>> SUMMARY | overcloud-computehci-1 | Wait for puppet host config >>> >> uration to finish | 90.37s >>> >> 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | >>> SUMMARY | overcloud-computehci-2 | Wait for puppet host config >>> >> uration to finish | 90.37s >>> >> 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | >>> SUMMARY | overcloud-computehci-0 | Wait for puppet host config >>> >> uration to finish | 90.35s >>> >> 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> State Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes which >>> did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >>> >> 2021-08-23 15:00:24.562379 | The following node(s) had failures: >>> undercloud >>> >> 2021-08-23 15:00:24.562456 | >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts >>> >> Ansible failed, check log at >>> /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: >>> http://10.0.2.40:5000 >>> >> Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard >>> >> Overcloud rc file: /home/stack/overcloudrc >>> >> Overcloud Deployed with error >>> >> Overcloud configuration failed. >>> >> >>> > >>> > >>> > Could someone help debug this, the ansible.log is huge, I can't see >>> what's the origin of the problem, if someone can point me to the right >>> direction it will aprecciated. >>> > Thanks in advance. >>> > >>> > Regards. >>> > >>> > Le mer. 18 août 2021 à 18:02, Wesley Hayutin a >>> écrit : >>> >> >>> >> >>> >> >>> >> 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 >>> >>> >>> >> >> -- >> Francesco Pantano >> GPG KEY: F41BD75C >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo at celati.com Tue Aug 24 21:27:03 2021 From: paolo at celati.com (Paolo Celati) Date: Tue, 24 Aug 2021 23:27:03 +0200 Subject: What OS image can I use for Docker Swarm in Magnum? Message-ID: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> Hi,   I'm looking to set up Docker Swarm using Openstack Magnum and I noticed the user guide for magnum lists only Fedora Atomic as supported.  If I'm not mistaken though Atomic has been discontinued for a while now, so I'm wondering what you use for this use case.  Can I use Fedora CoreOS instead, and if so are there any gotchas I should know as a first time Magnum user? Thanks in advance, Paolo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x6A5811658B827BE4.asc Type: application/pgp-keys Size: 3123 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From tonykarera at gmail.com Wed Aug 25 04:42:20 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 25 Aug 2021 06:42:20 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Guys, Thanks a lot for the help but unfortunately I dont see much information in the log file indicating a failure apart from the log that keeps appearing. [image: image.png] Regards Tony Karera On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser wrote: > Also check out /var/log/cloud-init.log :) > > On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed wrote: > > > > Then check journalctl -xe or status of heat agent service status. > > > > > > Ammad > > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony > wrote: > >> > >> Hello Ammad, > >> > >> There is no directory or log relevant to heat in the /var/log directory > >> > >> Regards > >> > >> Tony Karera > >> > >> > >> > >> > >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed > wrote: > >>> > >>> Hi Karera, > >>> > >>> Login to master node and check the logs of heat agent in var log. > There must be something the cluster is stucking somewhere in creating. > >>> > >>> Ammad > >>> > >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony > wrote: > >>>> > >>>> Hello Ammad, > >>>> > >>>> I had done as explained and it worked upto a certain point. The > master node was created but the cluster remained in Creation in progress > for over an hour and failed with error below > >>>> > >>>> Stack Faults > >>>> as follows: > >>>> default-master > >>>> Timed out > >>>> default-worker > >>>> Timed out > >>>> > >>>> > >>>> Regards > >>>> > >>>> Tony Karera > >>>> > >>>> > >>>> > >>>> > >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed > wrote: > >>>>> > >>>>> Hi Tony, > >>>>> > >>>>> You can try by creating your private vxlan network prior to > deployment of cluster and explicitly create your cluster in vxlan network. > >>>>> > >>>>> --fixed-network private --fixed-subnet private-subnet > >>>>> > >>>>> You can specify above while creating a cluster. > >>>>> > >>>>> Ammad > >>>>> > >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony > wrote: > >>>>>> > >>>>>> Hello MOhamed, > >>>>>> > >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It > creates a fixed network using vlan which I am not using for internal > networks. > >>>>>> > >>>>>> When I create a a vxlan Network and use it in the cluster creation, > It fails. Is there a trick around this ? > >>>>>> Regards > >>>>>> > >>>>>> Tony Karera > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong > wrote: > >>>>>>> > >>>>>>> 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 < > mnaser at vexxhost.com> wrote: > >>>>>>>>> > >>>>>>>>> What does your cluster template and cluster create command look > like? > >>>>>>>>> > >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < > tonykarera at gmail.com> 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 < > feilong at catalyst.net.nz> 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. > >>>>>>> > ------------------------------------------------------------------------------ > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Regards, > >>>>> > >>>>> > >>>>> Syed Ammad Ali > >>> > >>> > >>> > >>> -- > >>> Regards, > >>> > >>> > >>> Syed Ammad Ali > > > > -- > > Regards, > > > > > > Syed Ammad Ali > > > > -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: From anyrude10 at gmail.com Wed Aug 25 05:27:30 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Wed, 25 Aug 2021 10:57:30 +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 Julia, I have also upgraded my firmware to *P89 v2.90 (10/16/2020) *but still the result is the same. For your reference, the output of is openstack baremetal node show for whole disk image is as follows: [ansible at localhost ~]$ openstack baremetal node show baremetal-node -f json { "allocation_uuid": null, "automated_clean": null, "bios_interface": "no-bios", "boot_interface": "ipxe", "chassis_uuid": null, "clean_step": {}, "conductor": "controller", "conductor_group": "", "console_enabled": false, "console_interface": "no-console", "created_at": "2021-08-25T04:51:32+00:00", "deploy_interface": "direct", "deploy_step": {}, "description": null, "driver": "ipmi", "driver_info": { "ipmi_port": 623, "ipmi_username": "hsc", "ipmi_password": "******", "ipmi_address": "10.0.1.207", "deploy_kernel": "a34b7e57-f324-40fe-8fe4-04eb7ea49c3a", "deploy_ramdisk": "8db38567-4923-4322-b1bf-e12cce5cafc4" }, "driver_internal_info": { "clean_steps": null, "agent_erase_devices_iterations": 1, "agent_erase_devices_zeroize": true, "agent_continue_if_secure_erase_failed": false, "agent_continue_if_ata_erase_failed": false, "agent_enable_nvme_secure_erase": true, "agent_enable_ata_secure_erase": true, "disk_erasure_concurrency": 1, "agent_erase_skip_read_only": false, "last_power_state_change": "2021-08-25T05:10:16.671639", "agent_version": "7.0.2.dev10", "agent_last_heartbeat": "2021-08-25T05:09:34.904605", "hardware_manager_version": { "MellanoxDeviceHardwareManager": "1", "generic_hardware_manager": "1.1" }, "agent_cached_clean_steps_refreshed": "2021-08-25 04:59:28.312524", "is_whole_disk_image": true, "deploy_steps": null, "agent_cached_deploy_steps_refreshed": "2021-08-25 05:08:58.530633", "root_uuid_or_disk_id": "0x3f3df0d8" }, "extra": {}, "fault": null, "inspect_interface": "no-inspect", "inspection_finished_at": null, "inspection_started_at": null, "instance_info": { "image_source": "da92cd5d-e1d6-458d-a2b2-86e897a982c6", "root_gb": "470", "swap_mb": "0", "display_name": "server1", "vcpus": "24", "nova_host_id": "controller-ironic", "memory_mb": "62700", "local_gb": "470", "configdrive": "******", "image_disk_format": "raw", "image_checksum": null, "image_os_hash_algo": "sha512", "image_os_hash_value": "3b16d3a6734c23fb43fbd6deee16c907ea8e398bfd5163cd08f16ccd07a74399bb35f16a4713c3847058b445bf4150448f22eb11e75debcc548b8eaacf777e70", "image_url": "******", "image_container_format": "bare", "image_tags": [], "image_properties": { "stores": "file", "os_hidden": false, "virtual_size": 3511681024, "owner_specified.openstack.object": "images/centos-d", "owner_specified.openstack.sha256": "", "owner_specified.openstack.md5": "" }, "image_type": "whole-disk-image" }, "instance_uuid": "e29c267f-8ddb-4dce-a07c-18c4f7210010", "last_error": null, "lessee": null, "maintenance": false, "maintenance_reason": null, "management_interface": "ipmitool", "name": "baremetal-node", "network_data": {}, "network_interface": "flat", "owner": null, "power_interface": "ipmitool", "power_state": "power on", "properties": { "cpus": 30, "memory_mb": 62700, "local_gb": 470, "cpu_arch": "x86_64", "capabilities": "boot_mode:uefi,boot_option:local", "vendor": "hewlett-packard" }, "protected": false, "protected_reason": null, "provision_state": "active", "provision_updated_at": "2021-08-25T05:10:37+00:00", "raid_config": {}, "raid_interface": "no-raid", "rescue_interface": "no-rescue", "reservation": null, "resource_class": "baremetal-resource-class", "retired": false, "retired_reason": null, "storage_interface": "noop", "target_power_state": null, "target_provision_state": null, "target_raid_config": {}, "traits": [], "updated_at": "2021-08-25T05:10:37+00:00", "uuid": "3caaffe3-a6be-4b8c-b3dd-d302c4367670", "vendor_interface": "ipmitool" } I am not getting why this issue is not being reproduced with the partition disk image. Regards Anirudh Gupta On Mon, Aug 23, 2021 at 7:11 PM Julia Kreger wrote: > 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 < > juliaashleykreger at gmail.com> wrote: > >> > >> > >> > >> 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 syedammad83 at gmail.com Wed Aug 25 05:32:16 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 25 Aug 2021 10:32:16 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hi Karera, Can you share us the full log file. Ammad On Wed, Aug 25, 2021 at 9:42 AM Karera Tony wrote: > Hello Guys, > > Thanks a lot for the help but unfortunately I dont see much information in > the log file indicating a failure apart from the log that keeps appearing. > > [image: image.png] > > Regards > > Tony Karera > > > > > On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser > wrote: > >> Also check out /var/log/cloud-init.log :) >> >> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed wrote: >> > >> > Then check journalctl -xe or status of heat agent service status. >> > >> > >> > Ammad >> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >> wrote: >> >> >> >> Hello Ammad, >> >> >> >> There is no directory or log relevant to heat in the /var/log directory >> >> >> >> Regards >> >> >> >> Tony Karera >> >> >> >> >> >> >> >> >> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed >> wrote: >> >>> >> >>> Hi Karera, >> >>> >> >>> Login to master node and check the logs of heat agent in var log. >> There must be something the cluster is stucking somewhere in creating. >> >>> >> >>> Ammad >> >>> >> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony >> wrote: >> >>>> >> >>>> Hello Ammad, >> >>>> >> >>>> I had done as explained and it worked upto a certain point. The >> master node was created but the cluster remained in Creation in progress >> for over an hour and failed with error below >> >>>> >> >>>> Stack Faults >> >>>> as follows: >> >>>> default-master >> >>>> Timed out >> >>>> default-worker >> >>>> Timed out >> >>>> >> >>>> >> >>>> Regards >> >>>> >> >>>> Tony Karera >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed >> wrote: >> >>>>> >> >>>>> Hi Tony, >> >>>>> >> >>>>> You can try by creating your private vxlan network prior to >> deployment of cluster and explicitly create your cluster in vxlan network. >> >>>>> >> >>>>> --fixed-network private --fixed-subnet private-subnet >> >>>>> >> >>>>> You can specify above while creating a cluster. >> >>>>> >> >>>>> Ammad >> >>>>> >> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >> wrote: >> >>>>>> >> >>>>>> Hello MOhamed, >> >>>>>> >> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It >> creates a fixed network using vlan which I am not using for internal >> networks. >> >>>>>> >> >>>>>> When I create a a vxlan Network and use it in the cluster >> creation, It fails. Is there a trick around this ? >> >>>>>> Regards >> >>>>>> >> >>>>>> Tony Karera >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong >> wrote: >> >>>>>>> >> >>>>>>> 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 < >> mnaser at vexxhost.com> wrote: >> >>>>>>>>> >> >>>>>>>>> What does your cluster template and cluster create command look >> like? >> >>>>>>>>> >> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >> tonykarera at gmail.com> 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 < >> feilong at catalyst.net.nz> 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. >> >>>>>>> >> ------------------------------------------------------------------------------ >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Regards, >> >>>>> >> >>>>> >> >>>>> Syed Ammad Ali >> >>> >> >>> >> >>> >> >>> -- >> >>> Regards, >> >>> >> >>> >> >>> Syed Ammad Ali >> > >> > -- >> > Regards, >> > >> > >> > Syed Ammad Ali >> >> >> >> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: From tonykarera at gmail.com Wed Aug 25 06:20:32 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 25 Aug 2021 08:20:32 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Sir, Attached is the Log file Regards Tony Karera On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed wrote: > Hi Karera, > > Can you share us the full log file. > > Ammad > > On Wed, Aug 25, 2021 at 9:42 AM Karera Tony wrote: > >> Hello Guys, >> >> Thanks a lot for the help but unfortunately I dont see much information >> in the log file indicating a failure apart from the log that keeps >> appearing. >> >> [image: image.png] >> >> Regards >> >> Tony Karera >> >> >> >> >> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >> wrote: >> >>> Also check out /var/log/cloud-init.log :) >>> >>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>> wrote: >>> > >>> > Then check journalctl -xe or status of heat agent service status. >>> > >>> > >>> > Ammad >>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >>> wrote: >>> >> >>> >> Hello Ammad, >>> >> >>> >> There is no directory or log relevant to heat in the /var/log >>> directory >>> >> >>> >> Regards >>> >> >>> >> Tony Karera >>> >> >>> >> >>> >> >>> >> >>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed >>> wrote: >>> >>> >>> >>> Hi Karera, >>> >>> >>> >>> Login to master node and check the logs of heat agent in var log. >>> There must be something the cluster is stucking somewhere in creating. >>> >>> >>> >>> Ammad >>> >>> >>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony >>> wrote: >>> >>>> >>> >>>> Hello Ammad, >>> >>>> >>> >>>> I had done as explained and it worked upto a certain point. The >>> master node was created but the cluster remained in Creation in progress >>> for over an hour and failed with error below >>> >>>> >>> >>>> Stack Faults >>> >>>> as follows: >>> >>>> default-master >>> >>>> Timed out >>> >>>> default-worker >>> >>>> Timed out >>> >>>> >>> >>>> >>> >>>> Regards >>> >>>> >>> >>>> Tony Karera >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed >>> wrote: >>> >>>>> >>> >>>>> Hi Tony, >>> >>>>> >>> >>>>> You can try by creating your private vxlan network prior to >>> deployment of cluster and explicitly create your cluster in vxlan network. >>> >>>>> >>> >>>>> --fixed-network private --fixed-subnet private-subnet >>> >>>>> >>> >>>>> You can specify above while creating a cluster. >>> >>>>> >>> >>>>> Ammad >>> >>>>> >>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony >>> wrote: >>> >>>>>> >>> >>>>>> Hello MOhamed, >>> >>>>>> >>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It >>> creates a fixed network using vlan which I am not using for internal >>> networks. >>> >>>>>> >>> >>>>>> When I create a a vxlan Network and use it in the cluster >>> creation, It fails. Is there a trick around this ? >>> >>>>>> Regards >>> >>>>>> >>> >>>>>> Tony Karera >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong >>> wrote: >>> >>>>>>> >>> >>>>>>> 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 < >>> tonykarera at gmail.com> 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 < >>> mnaser at vexxhost.com> wrote: >>> >>>>>>>>> >>> >>>>>>>>> What does your cluster template and cluster create command >>> look like? >>> >>>>>>>>> >>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>> tonykarera at gmail.com> 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 < >>> feilong at catalyst.net.nz> 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. >>> >>>>>>> >>> ------------------------------------------------------------------------------ >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Regards, >>> >>>>> >>> >>>>> >>> >>>>> Syed Ammad Ali >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> >>> >>> >>> >>> Syed Ammad Ali >>> > >>> > -- >>> > Regards, >>> > >>> > >>> > Syed Ammad Ali >>> >>> >>> >>> -- >>> Mohammed Naser >>> VEXXHOST, Inc. >>> >> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cloud-init.log Type: application/octet-stream Size: 180110 bytes Desc: not available URL: From syedammad83 at gmail.com Wed Aug 25 06:27:06 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 25 Aug 2021 11:27:06 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: It seems from the logs that you are using fedora atomic. Can you try with FCOS 32 image. https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz Ammad On Wed, Aug 25, 2021 at 11:20 AM Karera Tony wrote: > Hello Sir, > > Attached is the Log file > > Regards > > Tony Karera > > > > > On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed wrote: > >> Hi Karera, >> >> Can you share us the full log file. >> >> Ammad >> >> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony wrote: >> >>> Hello Guys, >>> >>> Thanks a lot for the help but unfortunately I dont see much information >>> in the log file indicating a failure apart from the log that keeps >>> appearing. >>> >>> [image: image.png] >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>> wrote: >>> >>>> Also check out /var/log/cloud-init.log :) >>>> >>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>> wrote: >>>> > >>>> > Then check journalctl -xe or status of heat agent service status. >>>> > >>>> > >>>> > Ammad >>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >>>> wrote: >>>> >> >>>> >> Hello Ammad, >>>> >> >>>> >> There is no directory or log relevant to heat in the /var/log >>>> directory >>>> >> >>>> >> Regards >>>> >> >>>> >> Tony Karera >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed >>>> wrote: >>>> >>> >>>> >>> Hi Karera, >>>> >>> >>>> >>> Login to master node and check the logs of heat agent in var log. >>>> There must be something the cluster is stucking somewhere in creating. >>>> >>> >>>> >>> Ammad >>>> >>> >>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony >>>> wrote: >>>> >>>> >>>> >>>> Hello Ammad, >>>> >>>> >>>> >>>> I had done as explained and it worked upto a certain point. The >>>> master node was created but the cluster remained in Creation in progress >>>> for over an hour and failed with error below >>>> >>>> >>>> >>>> Stack Faults >>>> >>>> as follows: >>>> >>>> default-master >>>> >>>> Timed out >>>> >>>> default-worker >>>> >>>> Timed out >>>> >>>> >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed >>>> wrote: >>>> >>>>> >>>> >>>>> Hi Tony, >>>> >>>>> >>>> >>>>> You can try by creating your private vxlan network prior to >>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>> >>>>> >>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>> >>>>> >>>> >>>>> You can specify above while creating a cluster. >>>> >>>>> >>>> >>>>> Ammad >>>> >>>>> >>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>> tonykarera at gmail.com> wrote: >>>> >>>>>> >>>> >>>>>> Hello MOhamed, >>>> >>>>>> >>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It >>>> creates a fixed network using vlan which I am not using for internal >>>> networks. >>>> >>>>>> >>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>> creation, It fails. Is there a trick around this ? >>>> >>>>>> Regards >>>> >>>>>> >>>> >>>>>> Tony Karera >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong >>>> wrote: >>>> >>>>>>> >>>> >>>>>>> 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 < >>>> tonykarera at gmail.com> 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 < >>>> mnaser at vexxhost.com> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> What does your cluster template and cluster create command >>>> look like? >>>> >>>>>>>>> >>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>> tonykarera at gmail.com> 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 < >>>> feilong at catalyst.net.nz> 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. >>>> >>>>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Regards, >>>> >>>>> >>>> >>>>> >>>> >>>>> Syed Ammad Ali >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Regards, >>>> >>> >>>> >>> >>>> >>> Syed Ammad Ali >>>> > >>>> > -- >>>> > Regards, >>>> > >>>> > >>>> > Syed Ammad Ali >>>> >>>> >>>> >>>> -- >>>> Mohammed Naser >>>> VEXXHOST, Inc. >>>> >>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: From tonykarera at gmail.com Wed Aug 25 06:28:12 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 25 Aug 2021 08:28:12 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Ammad, I actually first used that one and it was also getting stuck. I will try this one again and update you with the Logs though. Regards Tony Karera On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed wrote: > It seems from the logs that you are using fedora atomic. Can you try with > FCOS 32 image. > > > https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz > > Ammad > > On Wed, Aug 25, 2021 at 11:20 AM Karera Tony wrote: > >> Hello Sir, >> >> Attached is the Log file >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed wrote: >> >>> Hi Karera, >>> >>> Can you share us the full log file. >>> >>> Ammad >>> >>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>> wrote: >>> >>>> Hello Guys, >>>> >>>> Thanks a lot for the help but unfortunately I dont see much information >>>> in the log file indicating a failure apart from the log that keeps >>>> appearing. >>>> >>>> [image: image.png] >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>>> wrote: >>>> >>>>> Also check out /var/log/cloud-init.log :) >>>>> >>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>> wrote: >>>>> > >>>>> > Then check journalctl -xe or status of heat agent service status. >>>>> > >>>>> > >>>>> > Ammad >>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >>>>> wrote: >>>>> >> >>>>> >> Hello Ammad, >>>>> >> >>>>> >> There is no directory or log relevant to heat in the /var/log >>>>> directory >>>>> >> >>>>> >> Regards >>>>> >> >>>>> >> Tony Karera >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed >>>>> wrote: >>>>> >>> >>>>> >>> Hi Karera, >>>>> >>> >>>>> >>> Login to master node and check the logs of heat agent in var log. >>>>> There must be something the cluster is stucking somewhere in creating. >>>>> >>> >>>>> >>> Ammad >>>>> >>> >>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony >>>>> wrote: >>>>> >>>> >>>>> >>>> Hello Ammad, >>>>> >>>> >>>>> >>>> I had done as explained and it worked upto a certain point. The >>>>> master node was created but the cluster remained in Creation in progress >>>>> for over an hour and failed with error below >>>>> >>>> >>>>> >>>> Stack Faults >>>>> >>>> as follows: >>>>> >>>> default-master >>>>> >>>> Timed out >>>>> >>>> default-worker >>>>> >>>> Timed out >>>>> >>>> >>>>> >>>> >>>>> >>>> Regards >>>>> >>>> >>>>> >>>> Tony Karera >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Tony, >>>>> >>>>> >>>>> >>>>> You can try by creating your private vxlan network prior to >>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>> >>>>> >>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>> >>>>> >>>>> >>>>> You can specify above while creating a cluster. >>>>> >>>>> >>>>> >>>>> Ammad >>>>> >>>>> >>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>> tonykarera at gmail.com> wrote: >>>>> >>>>>> >>>>> >>>>>> Hello MOhamed, >>>>> >>>>>> >>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, >>>>> It creates a fixed network using vlan which I am not using for internal >>>>> networks. >>>>> >>>>>> >>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>> creation, It fails. Is there a trick around this ? >>>>> >>>>>> Regards >>>>> >>>>>> >>>>> >>>>>> Tony Karera >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>> feilong at catalyst.net.nz> wrote: >>>>> >>>>>>> >>>>> >>>>>>> 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 < >>>>> tonykarera at gmail.com> 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 < >>>>> mnaser at vexxhost.com> wrote: >>>>> >>>>>>>>> >>>>> >>>>>>>>> What does your cluster template and cluster create command >>>>> look like? >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>> tonykarera at gmail.com> 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 < >>>>> feilong at catalyst.net.nz> 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. >>>>> >>>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Syed Ammad Ali >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Regards, >>>>> >>> >>>>> >>> >>>>> >>> Syed Ammad Ali >>>>> > >>>>> > -- >>>>> > Regards, >>>>> > >>>>> > >>>>> > Syed Ammad Ali >>>>> >>>>> >>>>> >>>>> -- >>>>> Mohammed Naser >>>>> VEXXHOST, Inc. >>>>> >>>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: From tonykarera at gmail.com Wed Aug 25 07:07:55 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 25 Aug 2021 09:07:55 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Ammad, I have deployed using the given image but I think there is an issue with keystone as per the screen shot below when I checked the master node's heat-container-agent status [image: image.png] Regards Tony Karera On Wed, Aug 25, 2021 at 8:28 AM Karera Tony wrote: > Hello Ammad, > > I actually first used that one and it was also getting stuck. > > I will try this one again and update you with the Logs though. > > > Regards > > Tony Karera > > > > > On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed wrote: > >> It seems from the logs that you are using fedora atomic. Can you try with >> FCOS 32 image. >> >> >> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >> >> Ammad >> >> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >> wrote: >> >>> Hello Sir, >>> >>> Attached is the Log file >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>> wrote: >>> >>>> Hi Karera, >>>> >>>> Can you share us the full log file. >>>> >>>> Ammad >>>> >>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>> wrote: >>>> >>>>> Hello Guys, >>>>> >>>>> Thanks a lot for the help but unfortunately I dont see much >>>>> information in the log file indicating a failure apart from the log that >>>>> keeps appearing. >>>>> >>>>> [image: image.png] >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>>>> wrote: >>>>> >>>>>> Also check out /var/log/cloud-init.log :) >>>>>> >>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>>> wrote: >>>>>> > >>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>> > >>>>>> > >>>>>> > Ammad >>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >>>>>> wrote: >>>>>> >> >>>>>> >> Hello Ammad, >>>>>> >> >>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>> directory >>>>>> >> >>>>>> >> Regards >>>>>> >> >>>>>> >> Tony Karera >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed >>>>>> wrote: >>>>>> >>> >>>>>> >>> Hi Karera, >>>>>> >>> >>>>>> >>> Login to master node and check the logs of heat agent in var log. >>>>>> There must be something the cluster is stucking somewhere in creating. >>>>>> >>> >>>>>> >>> Ammad >>>>>> >>> >>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony >>>>>> wrote: >>>>>> >>>> >>>>>> >>>> Hello Ammad, >>>>>> >>>> >>>>>> >>>> I had done as explained and it worked upto a certain point. The >>>>>> master node was created but the cluster remained in Creation in progress >>>>>> for over an hour and failed with error below >>>>>> >>>> >>>>>> >>>> Stack Faults >>>>>> >>>> as follows: >>>>>> >>>> default-master >>>>>> >>>> Timed out >>>>>> >>>> default-worker >>>>>> >>>> Timed out >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Regards >>>>>> >>>> >>>>>> >>>> Tony Karera >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>> syedammad83 at gmail.com> wrote: >>>>>> >>>>> >>>>>> >>>>> Hi Tony, >>>>>> >>>>> >>>>>> >>>>> You can try by creating your private vxlan network prior to >>>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>>> >>>>> >>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>> >>>>> >>>>>> >>>>> You can specify above while creating a cluster. >>>>>> >>>>> >>>>>> >>>>> Ammad >>>>>> >>>>> >>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>> tonykarera at gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello MOhamed, >>>>>> >>>>>> >>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, >>>>>> It creates a fixed network using vlan which I am not using for internal >>>>>> networks. >>>>>> >>>>>> >>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>> creation, It fails. Is there a trick around this ? >>>>>> >>>>>> Regards >>>>>> >>>>>> >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>> feilong at catalyst.net.nz> wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> 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 < >>>>>> tonykarera at gmail.com> 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 < >>>>>> mnaser at vexxhost.com> wrote: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> What does your cluster template and cluster create command >>>>>> look like? >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>> tonykarera at gmail.com> 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 < >>>>>> feilong at catalyst.net.nz> 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. >>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Regards, >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Syed Ammad Ali >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Regards, >>>>>> >>> >>>>>> >>> >>>>>> >>> Syed Ammad Ali >>>>>> > >>>>>> > -- >>>>>> > Regards, >>>>>> > >>>>>> > >>>>>> > Syed Ammad Ali >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mohammed Naser >>>>>> VEXXHOST, Inc. >>>>>> >>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> Syed Ammad Ali >>>> >>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 45483 bytes Desc: not available URL: From syedammad83 at gmail.com Wed Aug 25 08:39:57 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 25 Aug 2021 13:39:57 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Yes, keystone, Heat, Barbicane and magnum public endpoints must be reachable from master and worker nodes. You can use below guide for the reference as well. https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 Ammad On Wed, Aug 25, 2021 at 12:08 PM Karera Tony wrote: > Hello Ammad, > > I have deployed using the given image but I think there is an issue with > keystone as per the screen shot below when I checked the master node's > heat-container-agent status > > [image: image.png] > Regards > > Tony Karera > > > > > On Wed, Aug 25, 2021 at 8:28 AM Karera Tony wrote: > >> Hello Ammad, >> >> I actually first used that one and it was also getting stuck. >> >> I will try this one again and update you with the Logs though. >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed wrote: >> >>> It seems from the logs that you are using fedora atomic. Can you try >>> with FCOS 32 image. >>> >>> >>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>> >>> Ammad >>> >>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>> wrote: >>> >>>> Hello Sir, >>>> >>>> Attached is the Log file >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>> wrote: >>>> >>>>> Hi Karera, >>>>> >>>>> Can you share us the full log file. >>>>> >>>>> Ammad >>>>> >>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>> wrote: >>>>> >>>>>> Hello Guys, >>>>>> >>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>> information in the log file indicating a failure apart from the log that >>>>>> keeps appearing. >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>>>>> wrote: >>>>>> >>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>> >>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>>>> wrote: >>>>>>> > >>>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>>> > >>>>>>> > >>>>>>> > Ammad >>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony >>>>>>> wrote: >>>>>>> >> >>>>>>> >> Hello Ammad, >>>>>>> >> >>>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>>> directory >>>>>>> >> >>>>>>> >> Regards >>>>>>> >> >>>>>>> >> Tony Karera >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>> syedammad83 at gmail.com> wrote: >>>>>>> >>> >>>>>>> >>> Hi Karera, >>>>>>> >>> >>>>>>> >>> Login to master node and check the logs of heat agent in var >>>>>>> log. There must be something the cluster is stucking somewhere in creating. >>>>>>> >>> >>>>>>> >>> Ammad >>>>>>> >>> >>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>> tonykarera at gmail.com> wrote: >>>>>>> >>>> >>>>>>> >>>> Hello Ammad, >>>>>>> >>>> >>>>>>> >>>> I had done as explained and it worked upto a certain point. The >>>>>>> master node was created but the cluster remained in Creation in progress >>>>>>> for over an hour and failed with error below >>>>>>> >>>> >>>>>>> >>>> Stack Faults >>>>>>> >>>> as follows: >>>>>>> >>>> default-master >>>>>>> >>>> Timed out >>>>>>> >>>> default-worker >>>>>>> >>>> Timed out >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> Regards >>>>>>> >>>> >>>>>>> >>>> Tony Karera >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>> syedammad83 at gmail.com> wrote: >>>>>>> >>>>> >>>>>>> >>>>> Hi Tony, >>>>>>> >>>>> >>>>>>> >>>>> You can try by creating your private vxlan network prior to >>>>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>> >>>>> >>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>> >>>>> >>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>> >>>>> >>>>>>> >>>>> Ammad >>>>>>> >>>>> >>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>> tonykarera at gmail.com> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Hello MOhamed, >>>>>>> >>>>>> >>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, >>>>>>> It creates a fixed network using vlan which I am not using for internal >>>>>>> networks. >>>>>>> >>>>>> >>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>>> creation, It fails. Is there a trick around this ? >>>>>>> >>>>>> Regards >>>>>>> >>>>>> >>>>>>> >>>>>> Tony Karera >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 < >>>>>>> tonykarera at gmail.com> 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 < >>>>>>> mnaser at vexxhost.com> wrote: >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> What does your cluster template and cluster create command >>>>>>> look like? >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>> tonykarera at gmail.com> 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 < >>>>>>> feilong at catalyst.net.nz> 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. >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> Regards, >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> Syed Ammad Ali >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> Regards, >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> Syed Ammad Ali >>>>>>> > >>>>>>> > -- >>>>>>> > Regards, >>>>>>> > >>>>>>> > >>>>>>> > Syed Ammad Ali >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mohammed Naser >>>>>>> VEXXHOST, Inc. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >>>>> >>>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 45483 bytes Desc: not available URL: From wodel.youchi at gmail.com Wed Aug 25 12:38:08 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 25 Aug 2021 13:38:08 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> References: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> Message-ID: Hi and thanks I disabled the hide variable, and executed the command again, and this is the result : 2021-08-25 13:27:21.834140 | 52540075-9baf-e9c1-3396-0000000000a0 | > FATAL | Render network_config from template | computehci-1 | error={ > > "changed": false, > > > * "msg": "AnsibleUndefinedVariable: 'bond_interface_ovs_options' is > undefined" * > > } > I understand that this is a variable, but I don't see where it is being loaded from. I have a *network-environment-overrides.yaml* file which contains this : parameter_defaults: > ControllerNetworkConfigTemplate: > '/home/stack/templates/nic-configs/bonds_vlans.j2' > CephStorageNetworkConfigTemplate: > '/home/stack/templates/nic-configs/bonds_vlans.j2' > ComputeNetworkConfigTemplate: > '/home/stack/templates/nic-configs/bonds_vlans.j2' > > NeutronNetworkVLANRanges: 'datacentre:1:100,provider:400:1000' > NeutronExternalNetworkBridge: "''" > NeutronNetworkType: 'vlan,flat' > *BondInterfaceOvsOptions: "bond_mode=active-backup"* > But I don't see how to connect them? Regards. Le mer. 25 août 2021 à 09:08, Harald Jensas a écrit : > On 8/24/21 7:07 PM, wodel youchi wrote: > > *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 | > > FATAL | Render network_config from template | computehci-1 | > > error={ > > "censored": "the output has been hidden due to the fact that > > 'no_log: true' was specified for this result", > > "changed": false > > } > > This looks like a problem with your nic config template, > /home/stack/templates/nic-configs/bonds_vlans.j2. To debug disable > "hideing" of sensitive logs. > > sudo sed -i 's/tripleo_network_config_hide_sensitive_logs: > true/tripleo_network_config_hide_sensitive_logs: false/g' > /usr/share/ansible/roles/tripleo-network-config/defaults/main.yml > > > -- > Harald > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Wed Aug 25 12:57:05 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 25 Aug 2021 17:57:05 +0500 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> Message-ID: Hi Paolo, As far as I know, swarm clusters are unmaintained since 3 or 4 years. So it won't work as expected. Most of the magnum users are using kubernetes therefore its maintained. For kubernetes clusters you can use fedora CoreOS 32. It works perfectly fine. You can use below link for installation. https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10 Ammad On Wed, Aug 25, 2021 at 5:25 PM Paolo Celati wrote: > Hi, > > I'm looking to set up Docker Swarm using Openstack Magnum and I > noticed the user guide for magnum lists only Fedora Atomic as > supported. If I'm not mistaken though Atomic has been discontinued for > a while now, so I'm wondering what you use for this use case. Can I use > Fedora CoreOS instead, and if so are there any gotchas I should know as > a first time Magnum user? > > > Thanks in advance, > > Paolo > > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Wed Aug 25 13:30:41 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Wed, 25 Aug 2021 06:30:41 -0700 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Looking at the output, it looks correct. Except for the resource_class setting, but that has *nothing* to do with bootloading. :) I think we're going to need a log from the agent. Check the ``[agent]deploy_logs_collect``, ``[agent]deploy_logs_storage_backend``, and ``[agent]deploy_logs_local_path`` settings. Ideally you would be storing the deployment logs locally and you would be able to identify the instance from this node. One possibility, ironic could be doing the right thing,, but your disk image may not be able to be read/loaded by the firmware. For example, if a partition image is used, we create GPT partitioning, and try to find/extract the bootloader from within the image.. IF a whole disk image is used, we just write out what was supplied, and then attempt to look for the UEFI boot loader in the correct location, and then configure the system to boot using it. That is a bit of a stretch, but something you'll need to check because it may be that the firmware doesn't understand the partition type. Another possibility is that the UEFI specific overrides are invalid on ilo hardware which signals the machine to try to UEFI boot. This would be the first case we've heard of this. *generally* HPE recommends individuals/operators use their ilo driver for the best experience. An alternative is the redfish driver. Ilo is the known tested driver for HPE hardware, and redfish has UEFI boot settings encoded as part of the standard, where as IPMI was last revised in the 1990s. -Julia On Tue, Aug 24, 2021 at 10:27 PM Anirudh Gupta wrote: > > Hi Julia, > > I have also upgraded my firmware to P89 v2.90 (10/16/2020) but still the result is the same. > For your reference, the output of is openstack baremetal node show for whole disk image is as follows: > > [ansible at localhost ~]$ openstack baremetal node show baremetal-node -f json > { > "allocation_uuid": null, > "automated_clean": null, > "bios_interface": "no-bios", > "boot_interface": "ipxe", > "chassis_uuid": null, > "clean_step": {}, > "conductor": "controller", > "conductor_group": "", > "console_enabled": false, > "console_interface": "no-console", > "created_at": "2021-08-25T04:51:32+00:00", > "deploy_interface": "direct", > "deploy_step": {}, > "description": null, > "driver": "ipmi", > "driver_info": { > "ipmi_port": 623, > "ipmi_username": "hsc", > "ipmi_password": "******", > "ipmi_address": "10.0.1.207", > "deploy_kernel": "a34b7e57-f324-40fe-8fe4-04eb7ea49c3a", > "deploy_ramdisk": "8db38567-4923-4322-b1bf-e12cce5cafc4" > }, > "driver_internal_info": { > "clean_steps": null, > "agent_erase_devices_iterations": 1, > "agent_erase_devices_zeroize": true, > "agent_continue_if_secure_erase_failed": false, > "agent_continue_if_ata_erase_failed": false, > "agent_enable_nvme_secure_erase": true, > "agent_enable_ata_secure_erase": true, > "disk_erasure_concurrency": 1, > "agent_erase_skip_read_only": false, > "last_power_state_change": "2021-08-25T05:10:16.671639", > "agent_version": "7.0.2.dev10", > "agent_last_heartbeat": "2021-08-25T05:09:34.904605", > "hardware_manager_version": { > "MellanoxDeviceHardwareManager": "1", > "generic_hardware_manager": "1.1" > }, > "agent_cached_clean_steps_refreshed": "2021-08-25 04:59:28.312524", > "is_whole_disk_image": true, > "deploy_steps": null, > "agent_cached_deploy_steps_refreshed": "2021-08-25 05:08:58.530633", > "root_uuid_or_disk_id": "0x3f3df0d8" > }, > "extra": {}, > "fault": null, > "inspect_interface": "no-inspect", > "inspection_finished_at": null, > "inspection_started_at": null, > "instance_info": { > "image_source": "da92cd5d-e1d6-458d-a2b2-86e897a982c6", > "root_gb": "470", > "swap_mb": "0", > "display_name": "server1", > "vcpus": "24", > "nova_host_id": "controller-ironic", > "memory_mb": "62700", > "local_gb": "470", > "configdrive": "******", > "image_disk_format": "raw", > "image_checksum": null, > "image_os_hash_algo": "sha512", > "image_os_hash_value": "3b16d3a6734c23fb43fbd6deee16c907ea8e398bfd5163cd08f16ccd07a74399bb35f16a4713c3847058b445bf4150448f22eb11e75debcc548b8eaacf777e70", > "image_url": "******", > "image_container_format": "bare", > "image_tags": [], > "image_properties": { > "stores": "file", > "os_hidden": false, > "virtual_size": 3511681024, > "owner_specified.openstack.object": "images/centos-d", > "owner_specified.openstack.sha256": "", > "owner_specified.openstack.md5": "" > }, > "image_type": "whole-disk-image" > }, > "instance_uuid": "e29c267f-8ddb-4dce-a07c-18c4f7210010", > "last_error": null, > "lessee": null, > "maintenance": false, > "maintenance_reason": null, > "management_interface": "ipmitool", > "name": "baremetal-node", > "network_data": {}, > "network_interface": "flat", > "owner": null, > "power_interface": "ipmitool", > "power_state": "power on", > "properties": { > "cpus": 30, > "memory_mb": 62700, > "local_gb": 470, > "cpu_arch": "x86_64", > "capabilities": "boot_mode:uefi,boot_option:local", > "vendor": "hewlett-packard" > }, > "protected": false, > "protected_reason": null, > "provision_state": "active", > "provision_updated_at": "2021-08-25T05:10:37+00:00", > "raid_config": {}, > "raid_interface": "no-raid", > "rescue_interface": "no-rescue", > "reservation": null, > "resource_class": "baremetal-resource-class", > "retired": false, > "retired_reason": null, > "storage_interface": "noop", > "target_power_state": null, > "target_provision_state": null, > "target_raid_config": {}, > "traits": [], > "updated_at": "2021-08-25T05:10:37+00:00", > "uuid": "3caaffe3-a6be-4b8c-b3dd-d302c4367670", > "vendor_interface": "ipmitool" > } > > > I am not getting why this issue is not being reproduced with the partition disk image. > > Regards > Anirudh Gupta > > > > On Mon, Aug 23, 2021 at 7:11 PM Julia Kreger wrote: >> >> 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 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] From sgolovat at redhat.com Wed Aug 25 13:31:59 2021 From: sgolovat at redhat.com (Sergii Golovatiuk) Date: Wed, 25 Aug 2021 15:31:59 +0200 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2 James вт, 24 авг. 2021 г. в 14:16, James Slagle : > > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some of our upcoming challenges — the transition to CentOS/RHEL 9, increasing complexity around container management, and revisiting our commitments to our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review prioritization and in progress work streams. I would like to see folks representing review priorities during the TripleO meeting and on an etherpad. I'd also like to see less parallel streams of work, with the opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an approach. > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- -- Sergii Golovatiuk Senior Software Developer Red Hat From paolo at celati.com Wed Aug 25 13:02:52 2021 From: paolo at celati.com (Paolo Celati) Date: Wed, 25 Aug 2021 15:02:52 +0200 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> Message-ID: <5a8e2455-e5dc-a327-5c30-17c7e4d0875a@celati.com> Hi Ammad,   thanks for letting me know.  I suspected this could be the case, so I'll probably look into using Kubernetes instead. Paolo On 25/08/2021 14:57, Ammad Syed wrote: > Hi Paolo, > > As far as I know, swarm clusters are unmaintained since 3 or 4 years. > So it won't work as expected. > > Most of the magnum users are using kubernetes therefore its maintained. > > For kubernetes clusters you can use fedora CoreOS 32. It works > perfectly fine. > > You can use below link for installation. > > https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10 > > > Ammad > > On Wed, Aug 25, 2021 at 5:25 PM Paolo Celati > wrote: > > Hi, > >    I'm looking to set up Docker Swarm using Openstack Magnum and I > noticed the user guide for magnum lists only Fedora Atomic as > supported.  If I'm not mistaken though Atomic has been > discontinued for > a while now, so I'm wondering what you use for this use case. Can > I use > Fedora CoreOS instead, and if so are there any gotchas I should > know as > a first time Magnum user? > > > Thanks in advance, > > Paolo > > > > -- > Regards, > > > Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x6A5811658B827BE4.asc Type: application/pgp-keys Size: 3123 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From Hugo.Brito at windriver.com Wed Aug 25 13:49:47 2021 From: Hugo.Brito at windriver.com (Brito, Hugo Nicodemos) Date: Wed, 25 Aug 2021 13:49:47 +0000 Subject: [nova][dev] Improved scheduling error messages Message-ID: Hi, In a prototype, we have improved Nova's scheduling error messages. This helps both developers and end users better understand the scheduler problems that occur on creation of an instance. When a scheduler error happens during instance creation via the nova upstream, we get the following message on the Overview tab (Horizon dashboard): "No valid host was found." This doesn't give us enough information about what really happened, so our solution was to add more details on the instance's overview page, e.g.: **Fault:Message** attribute provides a summary of why each host can not satisfy the instance’s resource requirements, e.g. for controller-0, it indicates “No valid host was found. Not enough host cell CPUs to fit instance cell” (where cell is a numa-node or socket). **Fault:Details** attribute provides even more detail for each individual host, for example it shows that the instance “required” 2 CPU cores and shows the “actual” CPU cores available on each “numa” node: “actual:0, numa:1” and “actual:1, numa:0”. These details are also present using the OpenStack CLI, in the _fault_ attribute: - openstack server show With that in mind, we'd like to know if you are open to consider such a change. We are willing to submit a spec and upstream that implementation. Regards, - nicodemos -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Aug 25 13:50:08 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 25 Aug 2021 14:50:08 +0100 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> Message-ID: <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> On Wed, 2021-08-25 at 17:57 +0500, Ammad Syed wrote: > Hi Paolo, > > As far as I know, swarm clusters are unmaintained since 3 or 4 years. So it > won't work as expected. > > Most of the magnum users are using kubernetes therefore its maintained. > > For kubernetes clusters you can use fedora CoreOS 32. It works perfectly > fine. fedora 32 is no longer reciving any security or package updates as its EOL if you do base you deployment on fedora core os i would suggest using a more recent version. im not sure if will work with magnuma but i dont think we really should recommend using an unsupported OS for any new deployments. keep im mind that fedroa support policy is 2 release +1 month for hte base os. that tipically means its only supported for 13 months fedora 32 becamue EOL on 2021-05-25 3 months ago ideally if you are using fedora core os you would start form the most recent release and subscipe to t the stabel update stream https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/ the cloud image can be retrived here https://getfedora.org/coreos/download?tab=cloud_operators&stream=stable and the general openstack instuction are found here https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-openstack/ thse are really not targeted at magnum but rater makeing fedora core os avaiabel for other vms however you likely should use those images if they are compatibale with magnum. > > You can use below link for installation. > > https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10 > > Ammad > > On Wed, Aug 25, 2021 at 5:25 PM Paolo Celati wrote: > > > Hi, > > > > I'm looking to set up Docker Swarm using Openstack Magnum and I > > noticed the user guide for magnum lists only Fedora Atomic as > > supported. If I'm not mistaken though Atomic has been discontinued for > > a while now, so I'm wondering what you use for this use case. Can I use > > Fedora CoreOS instead, and if so are there any gotchas I should know as > > a first time Magnum user? > > > > > > Thanks in advance, > > > > Paolo > > > > > From abishop at redhat.com Wed Aug 25 13:52:17 2021 From: abishop at redhat.com (Alan Bishop) Date: Wed, 25 Aug 2021 06:52:17 -0700 Subject: [ops] [cinder] Cinder driver for Dell EMC PS Series on Train In-Reply-To: References: Message-ID: On Wed, Aug 25, 2021 at 1:55 AM Massimo Sgaravatto < massimo.sgaravatto at gmail.com> wrote: > Dear all > > In our Cloud we have multiple backends for Cinder. One of them is using > the Dell EMC PS Series volume driver > > My understanding (reading > https://docs.openstack.org/releasenotes/cinder/ussuri.html) is that the > driver doesn't work anymore in >= Ussuri > > A while ago we migrated to Train (using CentOS7 as operating system) and > everything kept working fine. > We are now trying to migrate to CentOS8 (still using Train) and the cinder > volume service for the equallogic backend doesn't work anymore > In the log file I found something like this [*] > > > We already planned to dismiss that backend (but we planned to do that > before next Openstack update). > > Does anyone know if that driver is supposed to work with Train and CentOS8 > (and therefore python3) ? > Hi Massimo, Per [1] and [2], Dell EMC deprecated their PS driver in Stein with the intention of removing it in Train. So no, the driver was not intended to work in Train. Dell EMC didn't address py3 issues because of their intent to remove the driver in Train. It turns out they didn't actually remove the driver in Train, but they did so in Ussuri [3]. But I would consider the driver to be non-functional in Train. [1] https://review.opendev.org/c/openstack/cinder/+/603441 [2] https://review.opendev.org/c/openstack/cinder/+/603441/6/releasenotes/notes/dell-emc-ps-deprecation-ae8d166e1847ea94.yaml [3] https://review.opendev.org/c/openstack/cinder/+/703839 Alan > Thanks, Massimo > > > [*] > 021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > [req-9fee10a8-4ad4-4bb3-a04c-46ef6919bb0f - - - - -] Error running > command.: TypeError: must be str, not bytes > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > Traceback (most recent call last): > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File > "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", > line 248, in _run_ssh > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > timeout=self.configuration.ssh_conn_timeout) > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File > "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", > line 72, in __inner > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > res = gt.wait() > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 181, > in wait > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > return self._exit_event.wait() > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File "/usr/lib/python3.6/site-packages/eventlet/event.py", line 125, in > wait > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > result = hub.switch() > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File "/usr/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in > switch > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > return self.greenlet.switch() > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 221, > in main > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > result = function(*args, **kwargs) > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File > "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", > line 196, in _ssh_execute > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > self._get_output(chan) > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > File > "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", > line 175, in _get_output > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > out += ret > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > TypeError: must be str, not bytes > 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Aug 25 13:56:01 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 25 Aug 2021 10:56:01 -0300 Subject: [cinder] Bug deputy report for week of 2021-25-08 Message-ID: This is a bug report from 2021-18-08 to 2021-25-08. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/1940540 "[oslo.utils] Usage of human output is deprecated in QemuImgInfo". Assigned to Takashi Kajinam. - https://bugs.launchpad.net/os-brick/+bug/1940608 "flush failed when both host and vm use lvm the multipath". Unassigned. Medium - https://bugs.launchpad.net/cinder/+bug/1941011 "Tests: Swift + S3 backup driver unit tests fail w/ RunTimeError". Unassigned. Wishlist - https://bugs.launchpad.net/cinder/+bug/1940669 "Add unit tests to check url and parameter for importing backups". Unassigned - https://bugs.launchpad.net/cinder/+bug/1940466 "Simultaneous volume creation with the same image in multiattach mode returns error". Assigned to Mitya Eremeev. - https://bugs.launchpad.net/cinder/+bug/1941062 " [Doc] Cinder retype installation is missing nova config". Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1940859 "[Stein] Multipathd delivers the wrong path to Cinde". Unassigned. Invalid - https://bugs.launchpad.net/cinder/+bug/1941068 "cinder-manage commands crash during db sync". Unassigned. 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 massimo.sgaravatto at gmail.com Wed Aug 25 14:02:39 2021 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Wed, 25 Aug 2021 16:02:39 +0200 Subject: [ops] [cinder] Cinder driver for Dell EMC PS Series on Train In-Reply-To: References: Message-ID: Thanks a lot Alan ! Maybe it is then worth reporting also in the release notes of Train that at least for python3 that driver doesn't work ... Thanks again Cheers, Massimo On Wed, Aug 25, 2021 at 3:52 PM Alan Bishop wrote: > > > On Wed, Aug 25, 2021 at 1:55 AM Massimo Sgaravatto < > massimo.sgaravatto at gmail.com> wrote: > >> Dear all >> >> In our Cloud we have multiple backends for Cinder. One of them is using >> the Dell EMC PS Series volume driver >> >> My understanding (reading >> https://docs.openstack.org/releasenotes/cinder/ussuri.html) is that the >> driver doesn't work anymore in >= Ussuri >> >> A while ago we migrated to Train (using CentOS7 as operating system) and >> everything kept working fine. >> We are now trying to migrate to CentOS8 (still using Train) and the >> cinder volume service for the equallogic backend doesn't work anymore >> In the log file I found something like this [*] >> >> >> We already planned to dismiss that backend (but we planned to do that >> before next Openstack update). >> >> Does anyone know if that driver is supposed to work with Train and >> CentOS8 (and therefore python3) ? >> > > Hi Massimo, > > Per [1] and [2], Dell EMC deprecated their PS driver in Stein with the > intention of removing it in Train. So no, the driver was not intended to > work in Train. Dell EMC didn't address py3 issues because of their intent > to remove the driver in Train. > > It turns out they didn't actually remove the driver in Train, but they did > so in Ussuri [3]. But I would consider the driver to be non-functional in > Train. > > [1] https://review.opendev.org/c/openstack/cinder/+/603441 > [2] > https://review.opendev.org/c/openstack/cinder/+/603441/6/releasenotes/notes/dell-emc-ps-deprecation-ae8d166e1847ea94.yaml > [3] https://review.opendev.org/c/openstack/cinder/+/703839 > > Alan > > >> Thanks, Massimo >> >> >> [*] >> 021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> [req-9fee10a8-4ad4-4bb3-a04c-46ef6919bb0f - - - - -] Error running >> command.: TypeError: must be str, not bytes >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> Traceback (most recent call last): >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File >> "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", >> line 248, in _run_ssh >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> timeout=self.configuration.ssh_conn_timeout) >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File >> "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", >> line 72, in __inner >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> res = gt.wait() >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 181, >> in wait >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> return self._exit_event.wait() >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File "/usr/lib/python3.6/site-packages/eventlet/event.py", line 125, in >> wait >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> result = hub.switch() >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File "/usr/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in >> switch >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> return self.greenlet.switch() >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File "/usr/lib/python3.6/site-packages/eventlet/greenthread.py", line 221, >> in main >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> result = function(*args, **kwargs) >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File >> "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", >> line 196, in _ssh_execute >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> self._get_output(chan) >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> File >> "/usr/lib/python3.6/site-packages/cinder/volume/drivers/dell_emc/ps.py", >> line 175, in _get_output >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> out += ret >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> TypeError: must be str, not bytes >> 2021-08-25 10:13:06.637 30932 ERROR cinder.volume.drivers.dell_emc.ps >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan.trellu at incloudus.com Wed Aug 25 14:48:50 2021 From: gaetan.trellu at incloudus.com (=?ISO-8859-1?Q?Ga=EBtan_Trellu?=) Date: Wed, 25 Aug 2021 08:48:50 -0600 Subject: [election][kolla] PTL candidacy for Yoga In-Reply-To: <169ec9ed-9470-cc15-5831-2c6c5e25e866@linaro.org> Message-ID: An HTML attachment was scrubbed... URL: From S.Kieske at mittwald.de Wed Aug 25 15:26:19 2021 From: S.Kieske at mittwald.de (Sven Kieske) Date: Wed, 25 Aug 2021 15:26:19 +0000 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> Message-ID: <96708068c7c0eff9a8366ff6397ef6e7e5e9ed13.camel@mittwald.de> On Mi, 2021-08-25 at 14:50 +0100, Sean Mooney wrote: > fedora 32 is no longer reciving any security or package updates as its EOL > if you do base you deployment on fedora core os i would suggest using a more recent version. > im not sure if will work with magnuma but i dont think we really should recommend using an unsupported > OS for any new deployments. > > keep im mind that fedroa support policy is 2 release +1 month for hte base os. > that tipically means its only supported for 13 months > fedora 32 becamue EOL on 2021-05-25 3 months ago fwiw I have seen (test)k8s clusters deployed with magnum which ran fedora coreos 34 more or less fine (I'm currently only aware of one bug, but there may be more). HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systementwickler / systems engineer     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 rlandy at redhat.com Wed Aug 25 16:11:29 2021 From: rlandy at redhat.com (Ronelle Landy) Date: Wed, 25 Aug 2021 12:11:29 -0400 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2. Thanks for stepping up to take this position. On Wed, Aug 25, 2021 at 9:35 AM Sergii Golovatiuk wrote: > +2 James > > вт, 24 авг. 2021 г. в 14:16, James Slagle : > > > > I'm submitting my candidacy for TripleO PTL. > > > > I look forward to the opportunity to help the community as we tackle > some of our upcoming challenges — the transition to CentOS/RHEL 9, > increasing complexity around container management, and revisiting our > commitments to our adopted tooling. > > > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > > > https://review.opendev.org/c/openstack/election/+/805840 > > > > -- > > -- James Slagle > > -- > > > > -- > Sergii Golovatiuk > > Senior Software Developer > > Red Hat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DHilsbos at performair.com Wed Aug 25 15:42:16 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Wed, 25 Aug 2021 15:42:16 +0000 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> Message-ID: <0670B960225633449A24709C291A525251C86EC8@COM03.performair.local> Kris; This shouldn’t be all that much more difficult than Linux, nor that much harder than a single-disk Windows VM. I would start by disabling the SQL service, as the OpenStack instance will boot once before you can add the data disks (at least it does for me when using Horizon). Export the disks, convert then, and import them, all as you normally would. Create the instance, as you normally would. The instance will start; shut it back down. Attach the additional volumes, and start the instance back up. It would be nice to have an option to not start the instance after creation. You could also investigate the “openstack server create” command; it has a --volume argument that you may be able to pass more than once, though I suspect not. 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: Tuesday, August 24, 2021 11:19 PM To: openstack-discuss at lists.openstack.org Subject: Re: Windows2012 VM image importing and Instance Launch Failure Thank you all. I am able to get the Single disk Windows VM exported from HyperV and imported to OpenStack(Ussuri, Glance and Qemu KVM ) Instance launched and its showing the status running in the PowerState Tab of Horizon dashboard. (need to check with the administrator user to login and confirm the VM is working as expected . ) My second phase : I need to perform importing multiple disk Windows VM to my OpenStack setup . ( For single disk Windows vhdx file, I 've converted it to qcow2 file and imported to OpenStack as the steps I posted in my previous emails. ) Now how can I import Multiple disk Windows VM to OpenStack. First Step is to convert the vhdx files exported from HyperV to qcow2 files. After this step , what steps need to be performed to bring a multi disk Windows VM to OpeStack ? For Eg: I have a Windows VM 1. with Application server 1TB single disk image exported from hyperV. This I can import to my OpenStack setup with the steps I followed in my earlier emails as it is a single disk image. 2. A Database server for the above application with 700 GB in multiple disks. ( 100 and 600 GB disks images exported from HyperV and in vhdx format for DB server) How to bring this server imported to my OpeStack setup (ussuri, glance and QEMU KVM). As this is from Windows HyperV I am new to multidisk environment from Windows. ( for Linux VMs exported from oVirt(RHVM) I am able to import multidisk VMs to OpenStack as they are in LVM and I have to mount it with VG name and adding entries in /etc/fstab file ) But in Windows multi disks how to perform this ? what steps I have to perform to import this to OpenStack. Any hints or suggestions most welcome.. Kris On Tue, Aug 24, 2021 at 1:40 PM Eugen Block > wrote: Of course you need a running nova-conductor, how did you launch VMs before? Zitat von KK CHN >: > 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 tonykarera at gmail.com Wed Aug 25 17:59:43 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 25 Aug 2021 19:59:43 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: DeaR Ammad, I was able to make the communication work and the Worker nodes were created as well but the cluster failed. I logged in to the master node and there was no error but below are the error when I run systemctl status heat-container-agent on the worker noed. Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping Regards Tony Karera On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed wrote: > Yes, keystone, Heat, Barbicane and magnum public endpoints must be > reachable from master and worker nodes. > > You can use below guide for the reference as well. > > > https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 > > Ammad > > On Wed, Aug 25, 2021 at 12:08 PM Karera Tony wrote: > >> Hello Ammad, >> >> I have deployed using the given image but I think there is an issue with >> keystone as per the screen shot below when I checked the master node's >> heat-container-agent status >> >> [image: image.png] >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony wrote: >> >>> Hello Ammad, >>> >>> I actually first used that one and it was also getting stuck. >>> >>> I will try this one again and update you with the Logs though. >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>> wrote: >>> >>>> It seems from the logs that you are using fedora atomic. Can you try >>>> with FCOS 32 image. >>>> >>>> >>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>> >>>> Ammad >>>> >>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>> wrote: >>>> >>>>> Hello Sir, >>>>> >>>>> Attached is the Log file >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>> wrote: >>>>> >>>>>> Hi Karera, >>>>>> >>>>>> Can you share us the full log file. >>>>>> >>>>>> Ammad >>>>>> >>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>>> wrote: >>>>>> >>>>>>> Hello Guys, >>>>>>> >>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>> information in the log file indicating a failure apart from the log that >>>>>>> keeps appearing. >>>>>>> >>>>>>> [image: image.png] >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>>>>>> wrote: >>>>>>> >>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>> >>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>>>> > >>>>>>>> > >>>>>>>> > Ammad >>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>> >> >>>>>>>> >> Hello Ammad, >>>>>>>> >> >>>>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>>>> directory >>>>>>>> >> >>>>>>>> >> Regards >>>>>>>> >> >>>>>>>> >> Tony Karera >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>> >>> >>>>>>>> >>> Hi Karera, >>>>>>>> >>> >>>>>>>> >>> Login to master node and check the logs of heat agent in var >>>>>>>> log. There must be something the cluster is stucking somewhere in creating. >>>>>>>> >>> >>>>>>>> >>> Ammad >>>>>>>> >>> >>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hello Ammad, >>>>>>>> >>>> >>>>>>>> >>>> I had done as explained and it worked upto a certain point. >>>>>>>> The master node was created but the cluster remained in Creation in >>>>>>>> progress for over an hour and failed with error below >>>>>>>> >>>> >>>>>>>> >>>> Stack Faults >>>>>>>> >>>> as follows: >>>>>>>> >>>> default-master >>>>>>>> >>>> Timed out >>>>>>>> >>>> default-worker >>>>>>>> >>>> Timed out >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Regards >>>>>>>> >>>> >>>>>>>> >>>> Tony Karera >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Hi Tony, >>>>>>>> >>>>> >>>>>>>> >>>>> You can try by creating your private vxlan network prior to >>>>>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>>> >>>>> >>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>> >>>>> >>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>> >>>>> >>>>>>>> >>>>> Ammad >>>>>>>> >>>>> >>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Hello MOhamed, >>>>>>>> >>>>>> >>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy >>>>>>>> it, It creates a fixed network using vlan which I am not using for internal >>>>>>>> networks. >>>>>>>> >>>>>> >>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>>>> creation, It fails. Is there a trick around this ? >>>>>>>> >>>>>> Regards >>>>>>>> >>>>>> >>>>>>>> >>>>>> Tony Karera >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> 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 < >>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>> command look like? >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>> >>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> -- >>>>>>>> >>>>> Regards, >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Syed Ammad Ali >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> -- >>>>>>>> >>> Regards, >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> Syed Ammad Ali >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Regards, >>>>>>>> > >>>>>>>> > >>>>>>>> > Syed Ammad Ali >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mohammed Naser >>>>>>>> VEXXHOST, Inc. >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> Syed Ammad Ali >>>>>> >>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> Syed Ammad Ali >>>> >>> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 75170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 45483 bytes Desc: not available URL: From wodel.youchi at gmail.com Wed Aug 25 20:45:40 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 25 Aug 2021 21:45:40 +0100 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hi, And thank you all for your help, I've managed to deploy my first overcloud. But, again I have another problem. I am using HCI deployment and I did include ceph dashboard in my deployment script, but I didn't find the dashboard, after reviewing the RedHat documentation, it seems that I have to use this role "ControllerStorageDashboard". This is what I did, but I got this : > > *RESP BODY: {"resources": [{"updated_time": "2021-08-25T20:14:20Z", > "creation_time": "2021-08-25T20:14:20Z", "logical_resource_id": "0", > "resource_name": "0", "physical_resource_id": > "a21b3498-fbdb-4a19-8e23-9dd71232b473", "resource_status": "CREATE_FAILED", > "resource_status_reason": "BadRequest: > resources[0].resources.OVNMacAddressPort: Invalid input for operation: > 'tripleo_ovn_mac_port_name=ControllerStorageDashboard-ovn-mac-0' exceeds > maximum length of 60.\nNeutron server returns request_ids: > ['req-467b58ef-dfd7-42c5-bb07-4f0f99b77332']", "resource_type": "OS* > ::TripleO::OVNMacAddressPort", "links": [{"href": " > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c7599a/stacks/overcloud-ControllerStorageDashboard-vtmxtvxpzggi-1-ue2d2riknvna-Cont > rollerStorageDashboardOVNChassisMacPorts-ui4dsb2tnkbk/ae81eb26-2f4b-4ae0-8826-af32be18ce14/resources/0", > "rel": "self"}, {"href": " > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c75 > 99a/stacks/overcloud-ControllerStorageDashboard-vtmxtvxpzggi-1-ue2d2riknvna-ControllerStorageDashboardOVNChassisMacPorts-ui4dsb2tnkbk/ae81eb26-2f4b-4ae0-8826-af32be18ce14", > "rel": "stack"}, > {"href": " > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c7599a/stacks/overcloud-ControllerStorageDashboard-vtmxtvxpzggi-1-ue2d2riknvna-ControllerStorageDashboardOVNChassisMacPorts > -ui4dsb2tnkbk-0-yfuxj4ahxviu/a21b3498-fbdb-4a19-8e23-9dd71232b473", "rel": > "nested"}], "required_by": [], "parent_resource": > "ControllerStorageDashboardOVNChassisMacPorts"}]} > GET call to orchestration for > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c7599a/stacks/overcloud-ControllerStorageDashboard-vtmxtvxpzggi-1-ue2d2riknvna-ControllerStorageDashboar > dOVNChassisMacPorts-ui4dsb2tnkbk/ae81eb26-2f4b-4ae0-8826-af32be18ce14/resources > used request id req-9609844f-f173-4e80-a3bd-bc287e88b00f > REQ: curl -g -i --cacert > "/etc/pki/ca-trust/source/anchors/cm-local-ca.pem" -X GET > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c7599a/stacks/a21b3498-fbdb-4a19-8e23-9dd71232b473/ > resources -H "Accept: application/json" -H "Content-Type: > application/json" -H "User-Agent: python-heatclient" -H "X-Auth-Token: > {SHA256}d296097c7cdf0beb50127e0a1d03cb8a702e18d543600f51b16d > ab4987811a6a" -H "X-Region-Name: " > https://10.200.24.2:13004 "GET > /v1/4f94deb9a28549c0a78f232756c7599a/stacks/a21b3498-fbdb-4a19-8e23-9dd71232b473/resources > HTTP/1.1" 302 649 > RESP: [302] Content-Length: 649 Content-Type: application/json Date: Wed, > 25 Aug 2021 20:15:11 GMT Location: > https://10.200.24.2:13004/v1/4f94deb9a28549c0a78f232756c7599a/stacks/overcloud-C > ontrollerStorageDashboard-vtmxtvxpzggi-1-ue2d2rik > ... > ... > overcloud.ControllerStorageDashboard.0.ControllerStorageDashboardOVNChassisMacPorts.0.OVNMacAddressPort: > resource_type: OS::Neutron::Port > physical_resource_id: 259e39f8-9e7b-4494-bb2d-ff7b2cf0ad40 > status: CREATE_FAILED > status_reason: | > > > > *BadRequest: resources.OVNMacAddressPort: Invalid input for operation: > 'tripleo_ovn_mac_port_name=ControllerStorageDashboard-ovn-mac-0' exceeds > maximum length of 60. Neutron server returns request_ids: > ['req-322ab0aa-0e1c-416f-be81-b48230d3dab1']overcloud.ControllerStorageDashboard.2.ControllerStorageDashboardOVNChassisMacPorts.0.OVNMacAddressPort: > resource_type: OS::Neutron::Port* > physical_resource_id: c7daf26b-7f96-43cf-8678-11d456b5cdfe > status: CREATE_FAILED > status_reason: | > BadRequest: resources.OVNMacAddressPort: Invalid input for operation: > 'tripleo_ovn_mac_port_name=ControllerStorageDashboard-ovn-mac-0' exceeds > maximum length of 60. > Neutron server returns request_ids: > ['req-9e3e19dd-4974-4007-9df0-ee9774369495'] > > overcloud.ControllerStorageDashboard.1.ControllerStorageDashboardOVNChassisMacPorts.0.OVNMacAddressPort: > resource_type: OS::Neutron::Port > physical_resource_id: c902e259-f299-457f-8b0d-c37fb40e0d32 > status: CREATE_FAILED > status_reason: | > BadRequest: resources.OVNMacAddressPort: Invalid input for operation: > 'tripleo_ovn_mac_port_name=ControllerStorageDashboard-ovn-mac-0' exceeds > maximum length of 60. > Neutron server returns request_ids: > ['req-467b58ef-dfd7-42c5-bb07-4f0f99b77332'] > clean_up ListStackFailures: > END return value: 0 > Instantiating messaging websocket client: wss://10.200.24.2:3000 > I couldn't find anything on the web about this error. Regards Le mar. 24 août 2021 à 22:25, wodel youchi a écrit : > Hello, > > After digging after grafana, it seems it needed to download something from > the internet, and i didn't really configure a proper gateway on the > external network. > So I started by configuring a proper gateway and I tested it with the half > deployed nodes, the I redid the deployment, and again I got this error : > > 2021-08-24 21:29:29.616805 | 525400e8-92c8-d397-6f7e-000000006133 | >> FATAL | Clean up legacy Cinder keystone catalog entries | undercloud | >> error={"changed": false, "module_stderr": "Fa >> iled to discover available identity versions when contacting >> http://10.0.2.40:5000. Attempting to parse version from URL.\nTraceback >> (most recent call last):\n File \"/usr/lib/python3.6/si >> te-packages/urllib3/connection.py\", line 162, in _new_conn\n >> (self._dns_host, self.port), self.timeout, **extra_kw)\n File >> \"/usr/lib/python3.6/site-packages/urllib3/util/connection.py >> \", line 80, in create_connection\n raise err\n File >> \"/usr/lib/python3.6/site-packages/urllib3/util/connection.py\", line 70, >> in create_connection\n sock.connect(sa)\nTimeoutError: >> [Errno 110] Connection timed out\n\nDuring handling of the above >> exception, another exception occurred:\n\nTraceback (most recent call >> last):\n File \"/usr/lib/python3.6/site-packages/urll >> ib3/connectionpool.py\", line 600, in urlopen\n chunked=chunked)\n >> File \"/usr/lib/python3.6/site-packages/urllib3/connectionpool.py\", line >> 354, in _make_request\n conn.request(meth >> od, url, **httplib_request_kw)\n File >> \"/usr/lib64/python3.6/http/client.py\", line 1269, in request\n >> self._send_request(method, url, body, headers, encode_chunked)\n File >> \"/usr/lib6 >> 4/python3.6/http/client.py\", line 1315, in _send_request\n >> self.endheaders(body, encode_chunked=encode_chunked)\n File >> \"/usr/lib64/python3.6/http/client.py\", line 1264, in endheaders >> \n self._send_output(message_body, encode_chunked=encode_chunked)\n >> File \"/usr/lib64/python3.6/http/client.py\", line 1040, in _send_output\n >> self.send(msg)\n File \"/usr/lib64/pyt >> hon3.6/http/client.py\", line 978, in send\n self.connect()\n File >> \"/usr/lib/python3.6/site-packages/urllib3/connection.py\", line 184, in >> connect\n conn = self._new_conn()\n File >> \"/usr/lib/python3.6/site-packages/urllib3/connection.py\", line 171, in >> _new_conn\n self, \"Failed to establish a new connection: %s\" % >> e)\nurllib3.exceptions.NewConnectionError: > ib3.connection.HTTPConnection object at 0x7f96f7b10cc0>: Failed to >> establish a new connection: [Errno 110] Connection timed out\n\nDuring >> handling of the above exception, another exception >> occurred:\n\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/requests/adapters.py\", line 449, in >> send\n timeout=timeout\n File \"/usr/lib/python3.6/site-p >> ackages/urllib3/connectionpool.py\", line 638, in urlopen\n >> _stacktrace=sys.exc_info()[2])\n File >> \"/usr/lib/python3.6/site-packages/urllib3/util/retry.py\", line 399, in >> increment\n >> raise MaxRetryError(_pool, url, error or >> ResponseError(cause))\nurllib3.exceptions.MaxRetryError: >> HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries exceeded with >> url: / (Caused >> by NewConnectionError('> 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno 110] >> Connection timed out',))\n\nDuring handling of the ab$ >> ve exception, another exception occurred:\n\nTraceback (most recent call >> last):\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 997, in >> _send_request\n resp $ >> self.session.request(method, url, **kwargs)\n File >> \"/usr/lib/python3.6/site-packages/requests/sessions.py\", line 533, in >> request\n resp = self.send(prep, **send_kwargs)\n File \"/u$ >> r/lib/python3.6/site-packages/requests/sessions.py\", line 646, in send\n >> r = adapter.send(request, **kwargs)\n File >> \"/usr/lib/python3.6/site-packages/requests/adapters.py\", line 516$ >> in send\n raise ConnectionError(e, >> request=request)\nrequests.exceptions.ConnectionError: >> HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries exceeded with >> url: / (Caused by N$wConnectionError('> object at 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno >> 110] Connection timed out',))\n\nDuring handling of the above e$ >> ception, another exception occurred:\n\nTraceback (most recent call >> last):\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", >> line 138, in _do_create_plug$ >> n\n authenticated=False)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/base.py\", line >> 610, in get_discovery\n authenticated=authenticated)\n File >> \"/usr/lib/pyt$ >> on3.6/site-packages/keystoneauth1/discover.py\", line 1442, in >> get_discovery\n disc = Discover(session, url, >> authenticated=authenticated)\n File >> \"/usr/lib/python3.6/site-packages/keys$ >> oneauth1/discover.py\", line 526, in __init__\n >> authenticated=authenticated)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/discover.py\", line 101, >> in get_version_data\n r$ >> sp = session.get(url, headers=headers, authenticated=authenticated)\n >> File \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line >> 1116, in get\n return self.request(url, '$ >> ET', **kwargs)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 906, in >> request\n resp = send(**kwargs)\n File >> \"/usr/lib/python3.6/site-packages/keystoneaut$ >> 1/session.py\", line 1013, in _send_request\n raise >> exceptions.ConnectFailure(msg)\nkeystoneauth1.exceptions.connection.ConnectFailure: >> Unable to establish connection to http://10.0.2.4$ >> :5000: HTTPConnectionPool(host='10.0.2.40', port=5000): Max retries >> exceeded with url: / (Caused by >> NewConnectionError('> 0x7f96f7b10cc0>: Failed >> to establish a new connection: [Errno 110] Connection timed >> out',))\n\nDuring handling of the above exception, another exception >> occurred:\n\nTraceback (most recent call last):\n File \"<$ >> tdin>\", line 102, in \n File \"\", line 94, in >> _ansiballz_main\n File \"\", line 40, in invoke_module\n File >> \"/usr/lib64/python3.6/runpy.py\", line 205, in run_m$ >> dule\n return _run_module_code(code, init_globals, run_name, >> mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in >> _run_module_code\n mod_name, mod_spec, pkg_name, script_$ >> ame)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n >> exec(code, run_globals)\n File >> \"/tmp/ansible_os_keystone_service_payload_wcyk6h37/ansible_os_keystone_service_p$ >> yload.zip/ansible/modules/cloud/openstack/os_keystone_service.py\", line >> 194, in \n File >> \"/tmp/ansible_os_keystone_service_payload_wcyk6h37/ansible_os_keystone_service_payload.zi$ >> /ansible/modules/cloud/openstack/os_keystone_service.py\", line 153, in >> main\n File >> \"/usr/lib/python3.6/site-packages/openstack/cloud/_identity.py\", line >> 510, in search_services\n se$ >> vices = self.list_services()\n File >> \"/usr/lib/python3.6/site-packages/openstack/cloud/_identity.py\", line >> 485, in list_services\n if self._is_client_version('identity', 2):\n >> File \$ >> /usr/lib/python3.6/site-packages/openstack/cloud/openstackcloud.py\", >> line 459, in _is_client_version\n client = getattr(self, client_name)\n >> File \"/usr/lib/python3.6/site-packages/op$ >> nstack/cloud/_identity.py\", line 32, in _identity_client\n >> 'identity', min_version=2, max_version='3.latest')\n File >> \"/usr/lib/python3.6/site-packages/openstack/cloud/openstackcloud.$ >> y\", line 406, in _get_versioned_client\n if adapter.get_endpoint():\n >> File \"/usr/lib/python3.6/site-packages/keystoneauth1/adapter.py\", line >> 282, in get_endpoint\n return self.se$ >> sion.get_endpoint(auth or self.auth, **kwargs)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/session.py\", line 1218, >> in get_endpoint\n return auth.get_endpoint(self, **kwarg$ >> )\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/base.py\", line >> 380, in get_endpoint\n allow_version_hack=allow_version_hack, >> **kwargs)\n File \"/usr/lib/python3.6/$ >> ite-packages/keystoneauth1/identity/base.py\", line 271, in >> get_endpoint_data\n service_catalog = >> self.get_access(session).service_catalog\n File >> \"/usr/lib/python3.6/site-packages/key$ >> toneauth1/identity/base.py\", line 134, in get_access\n self.auth_ref >> = self.get_auth_ref(session)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", >> l$ >> ne 206, in get_auth_ref\n self._plugin = >> self._do_create_plugin(session)\n File >> \"/usr/lib/python3.6/site-packages/keystoneauth1/identity/generic/base.py\", >> line 161, in _do_create_plu$ >> in\n 'auth_url is correct. %s' % >> e)\nkeystoneauth1.exceptions.discovery.DiscoveryFailure: Could not find >> versioned identity endpoints when attempting to authenticate. Please check >> that $our auth_url is correct. >> >> *Unable to establish connection to http://10.0.2.40:5000 >> : HTTPConnectionPool(host='10.0.2.40', port=5000): >> Max retries exceeded with url: / (Caused by >> NewConnectionError('> 0x7f96f7b10cc0>: Failed to establish a new connection: [Errno 110] >> Connection timed out',))\n", "module_stdout": "", "msg": "MODULE >> FAILURE\nSee stdout/stderr for the exact error", "rc": 1} * >> >> >> 2021-08-24 21:29:29.617697 | 525400e8-92c8-d397-6f7e-000000006133 | >> TIMING | Clean up legacy Cinder keystone catalog entries | undercloud | >> 1:07:40.666419 | 130.85s >> >> >> >> PLAY RECAP >> ********************************************************************* >> >> >> overcloud-computehci-0 : ok=260 changed=145 unreachable=0 >> failed=0 skipped=140 rescued=0 ignored=0 >> >> overcloud-computehci-1 : ok=258 changed=145 unreachable=0 >> failed=0 skipped=140 rescued=0 ignored=0 >> >> overcloud-computehci-2 : ok=255 changed=145 unreachable=0 >> failed=0 skipped=140 rescued=0 ignored=0 >> >> overcloud-controller-0 : ok=295 changed=181 unreachable=0 >> failed=0 skipped=151 rescued=0 ignored=0 >> >> overcloud-controller-1 : ok=289 changed=177 unreachable=0 >> failed=0 skipped=152 rescued=0 ignored=0 >> >> overcloud-controller-2 : ok=288 changed=177 unreachable=0 >> failed=0 skipped=152 rescued=0 ignored=0 >> >> undercloud : ok=105 changed=21 unreachable=0 >> failed=1 skipped=45 rescued=0 ignored=0 >> >> >> >> >> 2021-08-24 21:29:29.730778 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary >> Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-24 21:29:29.731007 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >> Tasks: 1723 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-24 21:29:29.731098 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: >> 1:07:40.779840 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> 2021-08-24 21:29:29.731172 | UUID | >> Info | Host | Task Name | Run Time >> >> 2021-08-24 21:29:29.731251 | 525400e8-92c8-d397-6f7e-000000003b9a | >> SUMMARY | undercloud | Run tripleo-container-image-prepare logged to: >> /var/log/tripleo-container-image-prepare.log | 1762.93s >> >> >> >> 2021-08-24 21:29:29.731349 | 525400e8-92c8-d397-6f7e-0000000057aa | >> SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ansible | >> 990.24s >> 2021-08-24 21:29:29.731433 | 525400e8-92c8-d397-6f7e-000000005951 | >> SUMMARY | overcloud-controller-0 | tripleo_ha_wrapper : Run init bundle >> puppet on the host for haproxy | 133.22s >> 2021-08-24 21:29:29.731503 | 525400e8-92c8-d397-6f7e-000000006133 | >> SUMMARY | undercloud | Clean up legacy Cinder keystone catalog entries | >> 130.85s >> 2021-08-24 21:29:29.731569 | 525400e8-92c8-d397-6f7e-000000006012 | >> SUMMARY | overcloud-controller-0 | Wait for containers to start for step 3 >> using paunch | 103.45s >> 2021-08-24 21:29:29.731643 | 525400e8-92c8-d397-6f7e-000000004337 | >> SUMMARY | overcloud-computehci-0 | Pre-fetch all the containers | 94.00s >> >> 2021-08-24 21:29:29.731729 | 525400e8-92c8-d397-6f7e-000000004378 | >> SUMMARY | overcloud-computehci-2 | Pre-fetch all the containers | 92.64s >> >> 2021-08-24 21:29:29.731795 | 525400e8-92c8-d397-6f7e-000000004337 | >> SUMMARY | overcloud-computehci-1 | Pre-fetch all the containers | 86.38s >> >> 2021-08-24 21:29:29.731867 | 525400e8-92c8-d397-6f7e-000000004d68 | >> SUMMARY | overcloud-controller-0 | Wait for container-puppet tasks >> (generate config) to finish | 84.13s >> 2021-08-24 21:29:29.731946 | 525400e8-92c8-d397-6f7e-000000004d99 | >> SUMMARY | overcloud-controller-2 | Wait for container-puppet tasks >> (generate config) to finish | 80.76s >> 2021-08-24 21:29:29.732012 | 525400e8-92c8-d397-6f7e-00000000427c | >> SUMMARY | overcloud-controller-1 | Pre-fetch all the containers | 80.21s >> >> 2021-08-24 21:29:29.732073 | 525400e8-92c8-d397-6f7e-00000000427c | >> SUMMARY | overcloud-controller-0 | Pre-fetch all the containers | 77.03s >> >> 2021-08-24 21:29:29.732138 | 525400e8-92c8-d397-6f7e-0000000042f5 | >> SUMMARY | overcloud-controller-2 | Pre-fetch all the containers | 76.32s >> >> 2021-08-24 21:29:29.732202 | 525400e8-92c8-d397-6f7e-000000004dd3 | >> SUMMARY | overcloud-controller-1 | Wait for container-puppet tasks >> (generate config) to finish | 74.36s >> 2021-08-24 21:29:29.732266 | 525400e8-92c8-d397-6f7e-000000005da7 | >> SUMMARY | overcloud-controller-0 | tripleo_ha_wrapper : Run init bundle >> puppet on the host for ovn_dbs | 68.39s >> 2021-08-24 21:29:29.732329 | 525400e8-92c8-d397-6f7e-000000005ce2 | >> SUMMARY | overcloud-controller-0 | Wait for containers to start for step 2 >> using paunch | 64.55s >> 2021-08-24 21:29:29.732398 | 525400e8-92c8-d397-6f7e-000000004b97 | >> SUMMARY | overcloud-controller-2 | Wait for puppet host configuration to >> finish | 58.13s >> 2021-08-24 21:29:29.732463 | 525400e8-92c8-d397-6f7e-000000004c1a | >> SUMMARY | overcloud-controller-1 | Wait for puppet host configuration to >> finish | 58.11s >> 2021-08-24 21:29:29.732526 | 525400e8-92c8-d397-6f7e-000000005bd3 | >> SUMMARY | overcloud-controller-1 | Wait for containers to start for step 2 >> using paunch | 58.09s >> 2021-08-24 21:29:29.732589 | 525400e8-92c8-d397-6f7e-000000005b9b | >> SUMMARY | overcloud-controller-2 | Wait for containers to start for step 2 >> using paunch | 58.09s >> > > > Thank you again for your assistance. > > Regards. > > Le mar. 24 août 2021 à 08:59, wodel youchi a > écrit : > >> Hi, and thanks for your help >> >> As for Ceph, here is container prepare >> parameter_defaults: >> ContainerImagePrepare: >> - push_destination: true >> set: >> ceph_alertmanager_image: alertmanager >> ceph_alertmanager_namespace: quay.ceph.io/prometheus >> ceph_alertmanager_tag: v0.16.2 >> ceph_grafana_image: grafana >> ceph_grafana_namespace: quay.ceph.io/app-sre >> *ceph_grafana_tag: 5.4.3* >> ceph_image: daemon >> ceph_namespace: quay.ceph.io/ceph-ci >> ceph_node_exporter_image: node-exporter >> ceph_node_exporter_namespace: quay.ceph.io/prometheus >> ceph_node_exporter_tag: v0.17.0 >> ceph_prometheus_image: prometheus >> ceph_prometheus_namespace: quay.ceph.io/prometheus >> ceph_prometheus_tag: v2.7.2 >> *ceph_tag: v4.0.19-stable-4.0-nautilus-centos-7-x86_64* >> name_prefix: centos-binary- >> name_suffix: '' >> namespace: quay.io/tripleotraincentos8 >> neutron_driver: ovn >> rhel_containers: false >> tag: current-tripleo >> tag_from_label: rdo_version >> >> And yes, the 10.200.7.0/24 network is my storage network >> Here is a snippet from my network_data.yaml >> >> - name: Storage >> vip: true >> vlan: 1107 >> name_lower: storage >> ip_subnet: '10.200.7.0/24' >> allocation_pools: [{'start': '10.200.7.150', 'end': '10.200.7.169'}] >> >> I will look into the grafana service to see why it's not booting and get >> back to you. >> >> Regards. >> >> Le lun. 23 août 2021 à 17:28, Francesco Pantano a >> écrit : >> >>> Hello, >>> thanks John for your reply here. >>> A few more comments inline: >>> >>> On Mon, Aug 23, 2021 at 6:16 PM John Fulton wrote: >>> >>>> On Mon, Aug 23, 2021 at 10:52 AM wodel youchi >>>> wrote: >>>> > >>>> > Hi, >>>> > >>>> > I redid the undercloud deployment for the Train version for now. And >>>> I verified the download URL for the images. >>>> > My overcloud deployment has moved forward but I still get errors. >>>> > >>>> > This is what I got this time : >>>> >> >>>> >> "TASK [ceph-grafana : wait for grafana to start] >>>> ********************************", >>>> >> "Monday 23 August 2021 14:55:21 +0100 (0:00:00.961) >>>> 0:12:59.319 ********* ", >>>> >> "fatal: [overcloud-controller-0]: FAILED! => {\"changed\": >>>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>>> >> 0.7.151:3100\"}", >>>> >> "fatal: [overcloud-controller-1]: FAILED! => {\"changed\": >>>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>>> >> 0.7.155:3100\"}", >>>> >> "fatal: [overcloud-controller-2]: FAILED! => {\"changed\": >>>> false, \"elapsed\": 300, \"msg\": \"Timeout when waiting for 10.20 >>>> >> 0.7.165:3100\"}", >>>> >>>> I'm not certain of the ceph-ansible version you're using but it should >>>> be a version 4 with train. ceph-ansible should already be installed on >>>> your undercloud judging by this error and in the latest version 4 this >>>> task is where it failed: >>>> >>>> >>>> https://github.com/ceph/ceph-ansible/blob/v4.0.64/roles/ceph-grafana/tasks/configure_grafana.yml#L112-L115 >>>> >>>> You can check the status of this service on your three controllers and >>>> then debug it directly. >>> >>> As John pointed out, ceph-ansible is able to configure, render and start >>> the associated >>> systemd unit for all the ceph monitoring stack components >>> (node-exported, prometheus, alertmanager and >>> grafana). >>> You can ssh to your controllers, and check the systemd unit associated, >>> checking the journal to see why >>> they failed to start (I saw there's a timeout waiting for the container >>> to start). >>> A potential plan, in this case, could be: >>> >>> 1. check the systemd unit (I guess you can start with grafana which is >>> the failed service) >>> 2. look at the journal logs (feel free to attach here the relevant part >>> of the output) >>> 3. double check the network where the service is bound (can you attach >>> the /var/lib/mistral//ceph-ansible/group_vars/all.yaml) >>> * The grafana process should be run on the storage network, but I >>> see a "Timeout when waiting for 10.200.7.165:3100": is that network the >>> right one? >>> >>>> >>> >>> >>>> John >>>> >>>> >> "RUNNING HANDLER [ceph-prometheus : service handler] >>>> ****************************", >>>> >> "Monday 23 August 2021 15:00:22 +0100 (0:05:00.767) >>>> 0:18:00.087 ********* ", >>>> >> "PLAY RECAP >>>> *********************************************************************", >>>> >> "overcloud-computehci-0 : ok=224 changed=23 >>>> unreachable=0 failed=0 skipped=415 rescued=0 ignored=0 ", >>>> >> "overcloud-computehci-1 : ok=199 changed=18 >>>> unreachable=0 failed=0 skipped=392 rescued=0 ignored=0 ", >>>> >> "overcloud-computehci-2 : ok=212 changed=23 >>>> unreachable=0 failed=0 skipped=390 rescued=0 ignored=0 ", >>>> >> "overcloud-controller-0 : ok=370 changed=52 >>>> unreachable=0 failed=1 skipped=539 rescued=0 ignored=0 ", >>>> >> "overcloud-controller-1 : ok=308 changed=43 >>>> unreachable=0 failed=1 skipped=495 rescued=0 ignored=0 ", >>>> >> "overcloud-controller-2 : ok=317 changed=45 >>>> unreachable=0 failed=1 skipped=493 rescued=0 ignored=0 ", >>>> >> >>>> >> "INSTALLER STATUS >>>> ***************************************************************", >>>> >> "Install Ceph Monitor : Complete (0:00:52)", >>>> >> "Install Ceph Manager : Complete (0:05:49)", >>>> >> "Install Ceph OSD : Complete (0:02:28)", >>>> >> "Install Ceph RGW : Complete (0:00:27)", >>>> >> "Install Ceph Client : Complete (0:00:33)", >>>> >> "Install Ceph Grafana : In Progress (0:05:54)", >>>> >> "\tThis phase can be restarted by running: >>>> roles/ceph-grafana/tasks/main.yml", >>>> >> "Install Ceph Node Exporter : Complete (0:00:28)", >>>> >> "Monday 23 August 2021 15:00:22 +0100 (0:00:00.006) >>>> 0:18:00.094 ********* ", >>>> >> >>>> "=============================================================================== >>>> ", >>>> >> "ceph-grafana : wait for grafana to start >>>> ------------------------------ 300.77s", >>>> >> "ceph-facts : get ceph current status >>>> ---------------------------------- 300.27s", >>>> >> "ceph-container-common : pulling >>>> udtrain.ctlplane.umaitek.dz:8787/ceph-ci/daemon:v4.0.19-stable-4.0-nautilus-centos-7-x86_64 >>>> >> image -- 19.04s", >>>> >> "ceph-mon : waiting for the monitor(s) to form the quorum... >>>> ------------ 12.83s", >>>> >> "ceph-osd : use ceph-volume lvm batch to create bluestore >>>> osds ---------- 12.13s", >>>> >> "ceph-osd : wait for all osd to be up >>>> ----------------------------------- 11.88s", >>>> >> "ceph-osd : set pg_autoscale_mode value on pool(s) >>>> ---------------------- 11.00s", >>>> >> "ceph-osd : create openstack pool(s) >>>> ------------------------------------ 10.80s", >>>> >> "ceph-grafana : make sure grafana is down >>>> ------------------------------- 10.66s", >>>> >> "ceph-osd : customize pool crush_rule >>>> ----------------------------------- 10.15s", >>>> >> "ceph-osd : customize pool size >>>> ----------------------------------------- 10.15s", >>>> >> "ceph-osd : customize pool min_size >>>> ------------------------------------- 10.14s", >>>> >> "ceph-osd : assign application to pool(s) >>>> ------------------------------- 10.13s", >>>> >> "ceph-osd : list existing pool(s) >>>> ---------------------------------------- 8.59s", >>>> >> >>>> >> "ceph-mon : fetch ceph initial keys >>>> -------------------------------------- 7.01s", >>>> >> "ceph-container-common : get ceph version >>>> -------------------------------- 6.75s", >>>> >> "ceph-prometheus : start prometheus services >>>> ----------------------------- 6.67s", >>>> >> "ceph-mgr : wait for all mgr to be up >>>> ------------------------------------ 6.66s", >>>> >> "ceph-grafana : start the grafana-server service >>>> ------------------------- 6.33s", >>>> >> "ceph-mgr : create ceph mgr keyring(s) on a mon node >>>> --------------------- 6.26s" >>>> >> ], >>>> >> "failed_when_result": true >>>> >> } >>>> >> 2021-08-23 15:00:24.427687 | 525400e8-92c8-47b1-e162-00000000597d | >>>> TIMING | tripleo-ceph-run-ansible : print ceph-ansible outpu$ >>>> >> in case of failure | undercloud | 0:37:30.226345 | 0.25s >>>> >> >>>> >> PLAY RECAP >>>> ********************************************************************* >>>> >> overcloud-computehci-0 : ok=213 changed=117 unreachable=0 >>>> failed=0 skipped=120 rescued=0 ignored=0 >>>> >> overcloud-computehci-1 : ok=207 changed=117 unreachable=0 >>>> failed=0 skipped=120 rescued=0 ignored=0 >>>> >> overcloud-computehci-2 : ok=207 changed=117 unreachable=0 >>>> failed=0 skipped=120 rescued=0 ignored=0 >>>> >> overcloud-controller-0 : ok=237 changed=145 unreachable=0 >>>> failed=0 skipped=128 rescued=0 ignored=0 >>>> >> overcloud-controller-1 : ok=232 changed=145 unreachable=0 >>>> failed=0 skipped=128 rescued=0 ignored=0 >>>> >> overcloud-controller-2 : ok=232 changed=145 unreachable=0 >>>> failed=0 skipped=128 rescued=0 ignored=0 >>>> >> undercloud : ok=100 changed=18 unreachable=0 >>>> failed=1 skipped=37 rescued=0 ignored=0 >>>> >> >>>> >> 2021-08-23 15:00:24.559997 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.560328 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total >>>> Tasks: 1366 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.560419 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed >>>> Time: 0:37:30.359090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.560490 | UUID | >>>> Info | Host | Task Name | Run Time >>>> >> 2021-08-23 15:00:24.560589 | 525400e8-92c8-47b1-e162-00000000597b | >>>> SUMMARY | undercloud | tripleo-ceph-run-ansible : run ceph-ans >>>> >> ible | 1082.71s >>>> >> 2021-08-23 15:00:24.560675 | 525400e8-92c8-47b1-e162-000000004d9a | >>>> SUMMARY | overcloud-controller-1 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 356.02s >>>> >> 2021-08-23 15:00:24.560763 | 525400e8-92c8-47b1-e162-000000004d6a | >>>> SUMMARY | overcloud-controller-0 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 355.74s >>>> >> 2021-08-23 15:00:24.560839 | 525400e8-92c8-47b1-e162-000000004dd0 | >>>> SUMMARY | overcloud-controller-2 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 355.68s >>>> >> 2021-08-23 15:00:24.560912 | 525400e8-92c8-47b1-e162-000000003bb1 | >>>> SUMMARY | undercloud | Run tripleo-container-image-prepare log >>>> >> ged to: /var/log/tripleo-container-image-prepare.log | 143.03s >>>> >> 2021-08-23 15:00:24.560986 | 525400e8-92c8-47b1-e162-000000004b13 | >>>> SUMMARY | overcloud-controller-0 | Wait for puppet host config >>>> >> uration to finish | 125.36s >>>> >> 2021-08-23 15:00:24.561057 | 525400e8-92c8-47b1-e162-000000004b88 | >>>> SUMMARY | overcloud-controller-2 | Wait for puppet host config >>>> >> uration to finish | 125.33s >>>> >> 2021-08-23 15:00:24.561128 | 525400e8-92c8-47b1-e162-000000004b4b | >>>> SUMMARY | overcloud-controller-1 | Wait for puppet host config >>>> >> uration to finish | 125.25s >>>> >> 2021-08-23 15:00:24.561300 | 525400e8-92c8-47b1-e162-000000001dc4 | >>>> SUMMARY | overcloud-controller-2 | Run puppet on the host to a >>>> >> pply IPtables rules | 108.08s >>>> >> 2021-08-23 15:00:24.561374 | 525400e8-92c8-47b1-e162-000000001e4f | >>>> SUMMARY | overcloud-controller-0 | Run puppet on the host to a >>>> >> pply IPtables rules | 107.34s >>>> >> 2021-08-23 15:00:24.561444 | 525400e8-92c8-47b1-e162-000000004c8d | >>>> SUMMARY | overcloud-computehci-2 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 96.56s >>>> >> 2021-08-23 15:00:24.561514 | 525400e8-92c8-47b1-e162-000000004c33 | >>>> SUMMARY | overcloud-computehci-0 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 96.38s >>>> >> 2021-08-23 15:00:24.561580 | 525400e8-92c8-47b1-e162-000000004c60 | >>>> SUMMARY | overcloud-computehci-1 | Wait for container-puppet t >>>> >> asks (generate config) to finish | 93.41s >>>> >> 2021-08-23 15:00:24.561645 | 525400e8-92c8-47b1-e162-00000000434d | >>>> SUMMARY | overcloud-computehci-0 | Pre-fetch all the container >>>> >> s | 92.70s >>>> >> 2021-08-23 15:00:24.561712 | 525400e8-92c8-47b1-e162-0000000043ed | >>>> SUMMARY | overcloud-computehci-2 | Pre-fetch all the container >>>> >> s | 91.90s >>>> >> 2021-08-23 15:00:24.561782 | 525400e8-92c8-47b1-e162-000000004385 | >>>> SUMMARY | overcloud-computehci-1 | Pre-fetch all the container >>>> >> s | 91.88s >>>> >> 2021-08-23 15:00:24.561876 | 525400e8-92c8-47b1-e162-00000000491c | >>>> SUMMARY | overcloud-computehci-1 | Wait for puppet host config >>>> >> uration to finish | 90.37s >>>> >> 2021-08-23 15:00:24.561947 | 525400e8-92c8-47b1-e162-000000004951 | >>>> SUMMARY | overcloud-computehci-2 | Wait for puppet host config >>>> >> uration to finish | 90.37s >>>> >> 2021-08-23 15:00:24.562016 | 525400e8-92c8-47b1-e162-0000000048e6 | >>>> SUMMARY | overcloud-computehci-0 | Wait for puppet host config >>>> >> uration to finish | 90.35s >>>> >> 2021-08-23 15:00:24.562080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End >>>> Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.562196 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> State Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.562311 | ~~~~~~~~~~~~~~~~~~ Number of nodes >>>> which did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ >>>> >> 2021-08-23 15:00:24.562379 | The following node(s) had failures: >>>> undercloud >>>> >> 2021-08-23 15:00:24.562456 | >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >> Host 10.0.2.40 not found in /home/stack/.ssh/known_hosts >>>> >> Ansible failed, check log at >>>> /var/lib/mistral/overcloud/ansible.log.Overcloud Endpoint: >>>> http://10.0.2.40:5000 >>>> >> Overcloud Horizon Dashboard URL: http://10.0.2.40:80/dashboard >>>> >> Overcloud rc file: /home/stack/overcloudrc >>>> >> Overcloud Deployed with error >>>> >> Overcloud configuration failed. >>>> >> >>>> > >>>> > >>>> > Could someone help debug this, the ansible.log is huge, I can't see >>>> what's the origin of the problem, if someone can point me to the right >>>> direction it will aprecciated. >>>> > Thanks in advance. >>>> > >>>> > Regards. >>>> > >>>> > Le mer. 18 août 2021 à 18:02, Wesley Hayutin a >>>> écrit : >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Aug 18, 2021 at 10:10 AM Dmitry Tantsur >>>> wrote: >>>> >>> >>>> >>> Hi, >>>> >>> >>>> >>> On Wed, Aug 18, 2021 at 4:39 PM wodel youchi < >>>> wodel.youchi at gmail.com> 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 >>>> >>>> >>>> >>> >>> -- >>> Francesco Pantano >>> GPG KEY: F41BD75C >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bharat at stackhpc.com Wed Aug 25 20:55:19 2021 From: bharat at stackhpc.com (Bharat Kunwar) Date: Wed, 25 Aug 2021 21:55:19 +0100 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: I’d check the logs under /var/log/heat-config. Sent from my iPhone > On 25 Aug 2021, at 19:39, Karera Tony wrote: > >  > DeaR Ammad, > > I was able to make the communication work and the Worker nodes were created as well but the cluster failed. > > I logged in to the master node and there was no error but below are the error when I run systemctl status heat-container-agent on the worker noed. > > Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping > Regards > > Tony Karera > > > > >> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed wrote: >> Yes, keystone, Heat, Barbicane and magnum public endpoints must be reachable from master and worker nodes. >> >> You can use below guide for the reference as well. >> >> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >> >> Ammad >> >>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony wrote: >>> Hello Ammad, >>> >>> I have deployed using the given image but I think there is an issue with keystone as per the screen shot below when I checked the master node's heat-container-agent status >>> >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony wrote: >>>> Hello Ammad, >>>> >>>> I actually first used that one and it was also getting stuck. >>>> >>>> I will try this one again and update you with the Logs though. >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed wrote: >>>>> It seems from the logs that you are using fedora atomic. Can you try with FCOS 32 image. >>>>> >>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>> >>>>> Ammad >>>>> >>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony wrote: >>>>>> Hello Sir, >>>>>> >>>>>> Attached is the Log file >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed wrote: >>>>>>> Hi Karera, >>>>>>> >>>>>>> Can you share us the full log file. >>>>>>> >>>>>>> Ammad >>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony wrote: >>>>>>>> Hello Guys, >>>>>>>> >>>>>>>> Thanks a lot for the help but unfortunately I dont see much information in the log file indicating a failure apart from the log that keeps appearing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser wrote: >>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>> >>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed wrote: >>>>>>>>> > >>>>>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Ammad >>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony wrote: >>>>>>>>> >> >>>>>>>>> >> Hello Ammad, >>>>>>>>> >> >>>>>>>>> >> There is no directory or log relevant to heat in the /var/log directory >>>>>>>>> >> >>>>>>>>> >> Regards >>>>>>>>> >> >>>>>>>>> >> Tony Karera >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed wrote: >>>>>>>>> >>> >>>>>>>>> >>> Hi Karera, >>>>>>>>> >>> >>>>>>>>> >>> Login to master node and check the logs of heat agent in var log. There must be something the cluster is stucking somewhere in creating. >>>>>>>>> >>> >>>>>>>>> >>> Ammad >>>>>>>>> >>> >>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> Hello Ammad, >>>>>>>>> >>>> >>>>>>>>> >>>> I had done as explained and it worked upto a certain point. The master node was created but the cluster remained in Creation in progress for over an hour and failed with error below >>>>>>>>> >>>> >>>>>>>>> >>>> Stack Faults >>>>>>>>> >>>> as follows: >>>>>>>>> >>>> default-master >>>>>>>>> >>>> Timed out >>>>>>>>> >>>> default-worker >>>>>>>>> >>>> Timed out >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Regards >>>>>>>>> >>>> >>>>>>>>> >>>> Tony Karera >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Hi Tony, >>>>>>>>> >>>>> >>>>>>>>> >>>>> You can try by creating your private vxlan network prior to deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>>>> >>>>> >>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>> >>>>> >>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Ammad >>>>>>>>> >>>>> >>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony wrote: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It creates a fixed network using vlan which I am not using for internal networks. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster creation, It fails. Is there a trick around this ? >>>>>>>>> >>>>>> Regards >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Tony Karera >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> 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. >>>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> -- >>>>>>>>> >>>>> Regards, >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> -- >>>>>>>>> >>> Regards, >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Syed Ammad Ali >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > Regards, >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Syed Ammad Ali >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mohammed Naser >>>>>>>>> VEXXHOST, Inc. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Syed Ammad Ali >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >> >> >> -- >> Regards, >> >> >> Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Aug 25 22:43:12 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 25 Aug 2021 17:43:12 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 26th at 1500 UTC In-Reply-To: <17b73bc6e2d.d8b0455b61221.2930938541566468414@ghanshyammann.com> References: <17b73bc6e2d.d8b0455b61221.2930938541566468414@ghanshyammann.com> Message-ID: <17b7f7b4f29.cf207c6f196019.2811311704869060679@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/ * Xena Cycle Tracker ** https://etherpad.opendev.org/p/tc-xena-tracker * 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 * Next step on pain points from projects/SIGs/pop-up (ricolin) ** https://etherpad.opendev.org/p/pain-point-elimination * Leaderless projects ** https://etherpad.opendev.org/p/yoga-leaderless * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 23 Aug 2021 10:58:53 -0500 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Aug 26th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Aug 25th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > > -gmann > > From ildiko.vancsa at gmail.com Thu Aug 26 00:00:38 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 25 Aug 2021 17:00:38 -0700 Subject: Edge for scientific research session on September 13 Edge WG meeting Message-ID: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> Hi, I’m very excited to invite you to a session with the Chameleon project to discuss how edge computing is powering education, scientific research and more! As always in the area of edge there are challenges and gaps that we need to solve together. In that sense the session will start with a presentation that we will then turn into a discussion to turn towards discussing solutions. Please also note that the Chameleon project is using OpenStack to build edge solutions. As they identified some gaps they would like to work with the community to address the challenges that they’ve been hitting. Please join us to get their feedback and find the best way to improve OpenStack to deliver a platform that can be used on the edge! The session will take place on the OpenInfra Edge Computing Group weekly call on __September 13, at 1300 UTC / 6am Pacific__. For the latest dial-in information please refer to this page: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Please find the details of the session below. Thanks and Best Regards, Ildikó Title: Chameleon: a cloud to edge infrastructure for science Abstract: The NSF-funded Chameleon project (www.chameleoncloud.org) provides an OpenStack-based bare metal reconfigurable cloud that supports systems research, education, and emergent application projects in science. The facility has been in existence for 6+ years, and has served ~6,000 users working on a variety of projects ranging from networking, operating systems design, and security, to innovative applications in astronomy, physics, and life sciences. Recent research trends in IoT and edge computing, as evidenced by increased numbers of project applications in those areas, made it clear that Chameleon needed to expand into the edge space. Remaining within the OpenStack framework allowed us to leverage end-user features that we developed for Chameleon, such as access via federated identity and Jupyter integration. Accordingly, we developed infrastructure called CHI at Edge that adapts Zun to provision containers on edge devices and significantly expands its capabilities to work in the edge space. The talk will describe our use case and the emergent product definition, the OpenStack adaptations we made to the current preview implementation, the directions we plan to take in our further work, as well as the ecosystem of projects and NSF infrastructure deployments leveraging this work and collaborating with us. From rosmaita.fossdev at gmail.com Thu Aug 26 04:03:58 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 26 Aug 2021 00:03:58 -0400 Subject: [cinder] high-priority reviews this week Message-ID: Hello Cinder team, As I mentioned at today's meeting, the cinderclient must be released next week, and this means that any Xena cinder features that we want supported in the Xena cinderclient need to merge into cinder first. We've got two cinder patches that introduce new microversions, and thus impact cinderclient. So please put the following patches at the top of your reviewing list: (1) "Snapshot in-use volumes without force flag" cinder: https://review.opendev.org/c/openstack/cinder/+/789564 cinderclient: (simply requires bump in MAX_VERSION, will be done in the release note patch) (2) "Expose volume & snapshot use_quota field" cinder: https://review.opendev.org/c/openstack/cinder/+/786386 cinderclient: https://review.opendev.org/c/openstack/python-cinderclient/+/787407 (very small patch) A slight complication is that 786386 is stacked on top of some other patches. On the other hand, these are all nicely done and present learning opportunities: - https://review.opendev.org/c/openstack/cinder/+/791240/ -- this is a good one to review if you're interested in how the automated tests to verify the request/response samples in the api-ref work - https://review.opendev.org/c/openstack/cinder/+/786383 -- relatively small patch with great unit test coverage - https://review.opendev.org/c/openstack/cinder/+/786384/ -- this is a good one if you want to get better acquainted with Cinder's use of Oslo Versioned Objects - https://review.opendev.org/c/openstack/cinder/+/786385 -- this is worth looking at to see the online data migration strategy Cinder uses to enable rolling upgrades - https://review.opendev.org/c/openstack/cinder/+/786386 -- this is the patch that introduces a new API microversion; it looks big, but a lot of the files are sample requests/responses for the api-ref Happy reviewing! From sz_cuitao at 163.com Thu Aug 26 05:28:02 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 13:28:02 +0800 Subject: why cannot launch the instance ? Message-ID: <001501d79a3b$24b33030$6e199090$@163.com> After the success deploy, I try to create a instance and launch it. But it failed. The error is : Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Code 500 Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Created Aug. 25, 2021, 3:23 p.m. Why ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Aug 26 06:55:30 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 26 Aug 2021 08:55:30 +0200 Subject: why cannot launch the instance ? In-Reply-To: <001501d79a3b$24b33030$6e199090$@163.com> References: <001501d79a3b$24b33030$6e199090$@163.com> Message-ID: On Thu, Aug 26, 2021 at 7:29 AM Tommy Sway wrote: > > After the success deploy, I try to create a instance and launch it. > > But it failed. > > The error is : > > > > > > Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Code 500 > > Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) > > nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Created Aug. 25, 2021, 3:23 p.m. > > > > > > Why ? > For the answer to that question you have to check the logs of nova-scheduler and possibly also nova-compute. -yoctozepto > > Thanks. > > > > From sz_cuitao at 163.com Thu Aug 26 07:11:51 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 15:11:51 +0800 Subject: why cannot launch the instance ? In-Reply-To: References: <001501d79a3b$24b33030$6e199090$@163.com> Message-ID: <004b01d79a49$a52933f0$ef7b9bd0$@163.com> But there's no log after I try to start the instance. [root at compute01 nova]# tail -f ./nova-compute.log 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/scheduler/client/report.py", line 1031, in set_traits_for_provider 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver if not self._provider_tree.have_traits_changed(rp_uuid, traits): 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 583, in have_traits_changed 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver provider = self._find_with_lock(name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 439, in _find_with_lock 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver raise ValueError(_("No such provider %s") % name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver ValueError: No such provider a613663b-3862-4a25-b3ae-4a13c11b7460 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver 2021-08-26 15:06:30.189 7 INFO nova.compute.manager [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] Looking for unclaimed instances stuck in BUILDING status for nodes managed by this host 2021-08-26 15:06:31.025 7 INFO nova.virt.libvirt.host [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] kernel doesn't support AMD SEV -----Original Message----- From: Radosław Piliszek Sent: Thursday, August 26, 2021 2:56 PM To: Tommy Sway Cc: openstack-discuss Subject: Re: why cannot launch the instance ? On Thu, Aug 26, 2021 at 7:29 AM Tommy Sway wrote: > > After the success deploy, I try to create a instance and launch it. > > But it failed. > > The error is : > > > > > > Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Code 500 > > Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) > > nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Created Aug. 25, 2021, 3:23 p.m. > > > > > > Why ? > For the answer to that question you have to check the logs of nova-scheduler and possibly also nova-compute. -yoctozepto > > Thanks. > > > > From skaplons at redhat.com Thu Aug 26 07:12:19 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 26 Aug 2021 09:12:19 +0200 Subject: [neutron] Drivers meeting agenda for 27.08.2021 Message-ID: <6050639.31TDG0VMnn@p1> Hi, Agenda for tomorrow's drivers meeting is at [1]. We have 2 RFEs to disuss: * https://bugs.launchpad.net/neutron/+bug/1936408 - [RFE] Neutron quota change should check available existing resources * https://bugs.launchpad.net/neutron/+bug/1939602 - [RFE] Add a memory profiler See You on the meeting tomorrow. [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 sz_cuitao at 163.com Thu Aug 26 07:19:07 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 15:19:07 +0800 Subject: why cannot launch the instance ? In-Reply-To: <004b01d79a49$a52933f0$ef7b9bd0$@163.com> References: <001501d79a3b$24b33030$6e199090$@163.com> <004b01d79a49$a52933f0$ef7b9bd0$@163.com> Message-ID: <004d01d79a4a$a974f1f0$fc5ed5d0$@163.com> I restart the compute node, and checked the log of the nova-compute: 2021-08-26 15:15:23.040 7 INFO nova.virt.libvirt.host [-] Secure Boot support detected 2021-08-26 15:15:23.359 7 WARNING nova.virt.libvirt.driver [req-97a00696-aa6b-40d2-8bc1-16a3dc00634a - - - - -] An error occurred while updating compute node resource provider status to "enabled" for provider: a613663b-3862-4a25-b3ae-4a13c11b7460: ValueError: No such provider a613663b-3862-4a25-b3ae-4a13c11b7460 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver Traceback (most recent call last): 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 4886, in _update_compute_provider_status 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver context, rp_uuid, enabled=not service.disabled) 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 522, in update_compute_provider_status 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver context, rp_uuid, new_traits, generation=trait_info.generation) 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/scheduler/client/report.py", line 73, in wrapper 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver return f(self, *a, **k) 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/scheduler/client/report.py", line 1031, in set_traits_for_provider 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver if not self._provider_tree.have_traits_changed(rp_uuid, traits): 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 583, in have_traits_changed 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver provider = self._find_with_lock(name_or_uuid) 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 439, in _find_with_lock 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver raise ValueError(_("No such provider %s") % name_or_uuid) 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver ValueError: No such provider a613663b-3862-4a25-b3ae-4a13c11b7460 2021-08-26 15:15:23.359 7 ERROR nova.virt.libvirt.driver 2021-08-26 15:15:23.510 7 INFO nova.compute.manager [req-21ebb01e-05cd-4f0c-841e-356ed8bff715 - - - - -] Looking for unclaimed instances stuck in BUILDING status for nodes managed by this host 2021-08-26 15:15:24.570 7 INFO nova.virt.libvirt.host [req-21ebb01e-05cd-4f0c-841e-356ed8bff715 - - - - -] kernel doesn't support AMD SEV What's the error about ? -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Thursday, August 26, 2021 3:12 PM To: 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: why cannot launch the instance ? But there's no log after I try to start the instance. [root at compute01 nova]# tail -f ./nova-compute.log 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/scheduler/client/report.py", line 1031, in set_traits_for_provider 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver if not self._provider_tree.have_traits_changed(rp_uuid, traits): 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 583, in have_traits_changed 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver provider = self._find_with_lock(name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 439, in _find_with_lock 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver raise ValueError(_("No such provider %s") % name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver ValueError: No such provider a613663b-3862-4a25-b3ae-4a13c11b7460 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver 2021-08-26 15:06:30.189 7 INFO nova.compute.manager [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] Looking for unclaimed instances stuck in BUILDING status for nodes managed by this host 2021-08-26 15:06:31.025 7 INFO nova.virt.libvirt.host [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] kernel doesn't support AMD SEV -----Original Message----- From: Radosław Piliszek Sent: Thursday, August 26, 2021 2:56 PM To: Tommy Sway Cc: openstack-discuss Subject: Re: why cannot launch the instance ? On Thu, Aug 26, 2021 at 7:29 AM Tommy Sway wrote: > > After the success deploy, I try to create a instance and launch it. > > But it failed. > > The error is : > > > > > > Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Code 500 > > Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) > > nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Created Aug. 25, 2021, 3:23 p.m. > > > > > > Why ? > For the answer to that question you have to check the logs of nova-scheduler and possibly also nova-compute. -yoctozepto > > Thanks. > > > > From sz_cuitao at 163.com Thu Aug 26 07:20:55 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 15:20:55 +0800 Subject: why cannot launch the instance ? In-Reply-To: <004b01d79a49$a52933f0$ef7b9bd0$@163.com> References: <001501d79a3b$24b33030$6e199090$@163.com> <004b01d79a49$a52933f0$ef7b9bd0$@163.com> Message-ID: <004f01d79a4a$e95a8500$bc0f8f00$@163.com> And when I try to start the instance, the error message on the web is : Error: You are not allowed to start instance: demo1 -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Thursday, August 26, 2021 3:12 PM To: 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: why cannot launch the instance ? But there's no log after I try to start the instance. [root at compute01 nova]# tail -f ./nova-compute.log 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/scheduler/client/report.py", line 1031, in set_traits_for_provider 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver if not self._provider_tree.have_traits_changed(rp_uuid, traits): 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 583, in have_traits_changed 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver provider = self._find_with_lock(name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver File "/usr/lib/python3.6/site-packages/nova/compute/provider_tree.py", line 439, in _find_with_lock 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver raise ValueError(_("No such provider %s") % name_or_uuid) 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver ValueError: No such provider a613663b-3862-4a25-b3ae-4a13c11b7460 2021-08-26 15:06:30.044 7 ERROR nova.virt.libvirt.driver 2021-08-26 15:06:30.189 7 INFO nova.compute.manager [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] Looking for unclaimed instances stuck in BUILDING status for nodes managed by this host 2021-08-26 15:06:31.025 7 INFO nova.virt.libvirt.host [req-af04cf38-b1ba-490d-ad70-e36a144bf068 - - - - -] kernel doesn't support AMD SEV -----Original Message----- From: Radosław Piliszek Sent: Thursday, August 26, 2021 2:56 PM To: Tommy Sway Cc: openstack-discuss Subject: Re: why cannot launch the instance ? On Thu, Aug 26, 2021 at 7:29 AM Tommy Sway wrote: > > After the success deploy, I try to create a instance and launch it. > > But it failed. > > The error is : > > > > > > Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Code 500 > > Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) > > nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. > > Created Aug. 25, 2021, 3:23 p.m. > > > > > > Why ? > For the answer to that question you have to check the logs of nova-scheduler and possibly also nova-compute. -yoctozepto > > Thanks. > > > > From ignaziocassano at gmail.com Thu Aug 26 07:37:38 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 26 Aug 2021 09:37:38 +0200 Subject: [kolla][wallaby] nova_libvirt restarting causes vm shutdown Message-ID: Hello, I tried to update kolla wallaby because new images has been released. During the update nova_libvirt container restarted and all vm went down. So I verified that every time I restart nova_libvirt container, all vm restarted and nova_compute reports lost connection with libvirt. In openstack installations where docker is not used, the libvirt restart does not cause vm shutdown. I opened a bug: https://bugs.launchpad.net/kolla-ansible/+bug/1941706 Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Thu Aug 26 07:41:28 2021 From: tobias.urdin at binero.com (Tobias Urdin) Date: Thu, 26 Aug 2021 07:41:28 +0000 Subject: [election][puppet] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: Hello, Even though the PTL nomination period is over, I would like to submit my candidacy for Puppet OpenStack in the hope that you will have me. I’ve been involved in OpenStack since around 2014, got involved with Puppet OpenStack in 2016, has been a core reviewer since 2018 and also held the PTL position for the Stein cycle. The Puppet OpenStack project is in a very mature state, the majority of our work is staying up-to-date with the constant changes to configuration options and general deployment topology changes but the interface itself is considered very stable and we have a very rigorous stable backport policy that helps us. We have a lot of major work done the last cycles, moving to CentOS 8, moving to CentOS Stream, adding support for Puppet 7 etc. We’ve also seen a major amount of cleanup and fixes to the policy (JSON to YAML) code (thanks Takashi!). The Puppet OpenStack team is limited and we therefore don’t hold any meetings and instead rely on the #puppet-openstack IRC channel for communications (come and say hello!). Best regards Tobias Urdin, Binero —— In the hopes that this will help the TC when following the leaderless-program policy for appointing a PTL. This candidacy is available in review: https://review.opendev.org/c/openstack/election/+/806099 -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Thu Aug 26 08:05:36 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Thu, 26 Aug 2021 13:05:36 +0500 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> Message-ID: Hi, There are some bugs reported for FCOS 34 with magnum cluster, kublet failed to start on FCOS 34 because of cgroup v2. https://storyboard.openstack.org/#!/story/2009045 Ammad On Wed, Aug 25, 2021 at 6:50 PM Sean Mooney wrote: > On Wed, 2021-08-25 at 17:57 +0500, Ammad Syed wrote: > > Hi Paolo, > > > > As far as I know, swarm clusters are unmaintained since 3 or 4 years. So > it > > won't work as expected. > > > > Most of the magnum users are using kubernetes therefore its maintained. > > > > For kubernetes clusters you can use fedora CoreOS 32. It works perfectly > > fine. > fedora 32 is no longer reciving any security or package updates as its EOL > if you do base you deployment on fedora core os i would suggest using a > more recent version. > im not sure if will work with magnuma but i dont think we really should > recommend using an unsupported > OS for any new deployments. > > keep im mind that fedroa support policy is 2 release +1 month for hte base > os. > that tipically means its only supported for 13 months > fedora 32 becamue EOL on 2021-05-25 3 months ago > > ideally if you are using fedora core os you would start form the most > recent release and subscipe to t the stabel update > stream https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/ > the cloud image can be retrived here > https://getfedora.org/coreos/download?tab=cloud_operators&stream=stable > > and the general openstack instuction are found here > https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-openstack/ > thse are really not targeted at magnum but rater makeing fedora core os > avaiabel for other vms however you likely should > use those images if they are compatibale with magnum. > > > > > > > You can use below link for installation. > > > > > https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10 > > > > Ammad > > > > On Wed, Aug 25, 2021 at 5:25 PM Paolo Celati wrote: > > > > > Hi, > > > > > > I'm looking to set up Docker Swarm using Openstack Magnum and I > > > noticed the user guide for magnum lists only Fedora Atomic as > > > supported. If I'm not mistaken though Atomic has been discontinued for > > > a while now, so I'm wondering what you use for this use case. Can I > use > > > Fedora CoreOS instead, and if so are there any gotchas I should know as > > > a first time Magnum user? > > > > > > > > > Thanks in advance, > > > > > > Paolo > > > > > > > > > > > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrishikesh.karanjikar at gmail.com Thu Aug 26 10:01:09 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Thu, 26 Aug 2021 15:31:09 +0530 Subject: Support for ONOS Message-ID: Hi, Does Openstack latest release support ONOS? -- Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From sshnaidm at redhat.com Thu Aug 26 10:10:04 2021 From: sshnaidm at redhat.com (Sagi Shnaidman) Date: Thu, 26 Aug 2021 13:10:04 +0300 Subject: [election][TripleO] James Slagle candidacy for TripleO PTL for Yoga In-Reply-To: References: Message-ID: +2! On Tue, Aug 24, 2021 at 3:24 PM James Slagle wrote: > I'm submitting my candidacy for TripleO PTL. > > I look forward to the opportunity to help the community as we tackle some > of our upcoming challenges — the transition to CentOS/RHEL 9, increasing > complexity around container management, and revisiting our commitments to > our adopted tooling. > > I'd suggest that to assist with these efforts, we focus on our review > prioritization and in progress work streams. I would like to see folks > representing review priorities during the TripleO meeting and on an > etherpad. I'd also like to see less parallel streams of work, with the > opportunity for more folks to collaborate on common priorities. > > If elected as PTL, I would plan to organize the efforts around such an > approach. > > Thank you for the consideration. > > https://review.opendev.org/c/openstack/election/+/805840 > > -- > -- James Slagle > -- > -- Best regards Sagi Shnaidman -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Aug 26 10:12:26 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 26 Aug 2021 11:12:26 +0100 Subject: [cinder] high-priority reviews this week In-Reply-To: References: Message-ID: On Thu, 2021-08-26 at 00:03 -0400, Brian Rosmaita wrote: > Hello Cinder team, > > As I mentioned at today's meeting, the cinderclient must be released > next week, and this means that any Xena cinder features that we want > supported in the Xena cinderclient need to merge into cinder first. > We've got two cinder patches that introduce new microversions, and thus > impact cinderclient. So please put the following patches at the top of > your reviewing list: I realize that this is not tied to a cinderclient release, but can I please ask that sqlalchemy-migrate -> alembic series [1] be included on this list also? Milestone 3 is very close and I will not be able to continue work on this next cycle. I'm also on holiday for two weeks starting September 6th. There are only 8 patches remaining so let's get this over the line while I'm still around and still have context. Cheers, Stephen [1] https://review.opendev.org/q/topic:%2522bp/remove-sqlalchemy-migrate%2522+status:open+project:openstack/cinder > > (1) "Snapshot in-use volumes without force flag" > cinder: https://review.opendev.org/c/openstack/cinder/+/789564 > cinderclient: (simply requires bump in MAX_VERSION, will be done in the > release note patch) > > (2) "Expose volume & snapshot use_quota field" > cinder: https://review.opendev.org/c/openstack/cinder/+/786386 > cinderclient: > https://review.opendev.org/c/openstack/python-cinderclient/+/787407 > (very small patch) > > A slight complication is that 786386 is stacked on top of some other > patches. On the other hand, these are all nicely done and present > learning opportunities: > > - https://review.opendev.org/c/openstack/cinder/+/791240/ -- this is a > good one to review if you're interested in how the automated tests to > verify the request/response samples in the api-ref work > > - https://review.opendev.org/c/openstack/cinder/+/786383 -- relatively > small patch with great unit test coverage > > - https://review.opendev.org/c/openstack/cinder/+/786384/ -- this is a > good one if you want to get better acquainted with Cinder's use of Oslo > Versioned Objects > > - https://review.opendev.org/c/openstack/cinder/+/786385 -- this is > worth looking at to see the online data migration strategy Cinder uses > to enable rolling upgrades > > - https://review.opendev.org/c/openstack/cinder/+/786386 -- this is the > patch that introduces a new API microversion; it looks big, but a lot of > the files are sample requests/responses for the api-ref > > > Happy reviewing! > From smooney at redhat.com Thu Aug 26 10:57:17 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 26 Aug 2021 11:57:17 +0100 Subject: Support for ONOS In-Reply-To: References: Message-ID: On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > Hi, > > Does Openstack latest release support ONOS? the short answer is no technially upstream has never supported it because it was a big tent projec that was never an offical deliverable of the netwroking team. https://github.com/openstack-archive/networking-onos has been retired as has https://opendev.org/openstack/networking-onos. the last release seams to have been from train but even then im not sure that it was still active. it looks like the onos projecct move the openstack install info under teh obsolete paages https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per+each+OpenStack+version so it does not look like the intend to support openstack anymore. > From hrishikesh.karanjikar at gmail.com Thu Aug 26 11:11:30 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Thu, 26 Aug 2021 16:41:30 +0530 Subject: Support for ONOS In-Reply-To: References: Message-ID: Hi Sean, Thanks for your reply. I was expecting the same answer as I also read the github link you sent. I may need to try older versions of openstack in that case. Hrishikesh On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney wrote: > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > Hi, > > > > Does Openstack latest release support ONOS? > the short answer is no > technially upstream has never supported it because it was a big tent > projec that was > never an offical deliverable of the netwroking team. > https://github.com/openstack-archive/networking-onos has been retired > as has https://opendev.org/openstack/networking-onos. the last release > seams to have been from train but > even then im not sure that it was still active. > it looks like the onos projecct move the openstack install info under teh > obsolete paages > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per+each+OpenStack+version > so it does not look like the intend to support openstack anymore. > > > > > > -- Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From beagles at redhat.com Thu Aug 26 11:13:45 2021 From: beagles at redhat.com (Brent Eagles) Date: Thu, 26 Aug 2021 08:43:45 -0230 Subject: [election][puppet] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: On Thu, Aug 26, 2021 at 07:41:28AM +0000, Tobias Urdin wrote: > Hello, > > Even though the PTL nomination period is over, I would like to submit my candidacy for Puppet OpenStack in the > hope that you will have me. > > I’ve been involved in OpenStack since around 2014, got involved with Puppet OpenStack in 2016, has been a > core reviewer since 2018 and also held the PTL position for the Stein cycle. > > The Puppet OpenStack project is in a very mature state, the majority of our work is staying up-to-date with the > constant changes to configuration options and general deployment topology changes but the interface itself is > considered very stable and we have a very rigorous stable backport policy that helps us. > > We have a lot of major work done the last cycles, moving to CentOS 8, moving to CentOS Stream, adding support > for Puppet 7 etc. We’ve also seen a major amount of cleanup and fixes to the policy (JSON to YAML) code (thanks Takashi!). > > The Puppet OpenStack team is limited and we therefore don’t hold any meetings and instead rely on the #puppet-openstack > IRC channel for communications (come and say hello!). > > Best regards > Tobias Urdin, Binero > > > —— > > In the hopes that this will help the TC when following the leaderless-program policy for appointing a PTL. > This candidacy is available in review: https://review.opendev.org/c/openstack/election/+/806099 'unofficial' +1. Thanks for volunteering Tobias! Cheers, Brent -- Brent Eagles Principal Software Engineer Red Hat Inc. From smooney at redhat.com Thu Aug 26 11:30:14 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 26 Aug 2021 12:30:14 +0100 Subject: Support for ONOS In-Reply-To: References: Message-ID: On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > Hi Sean, > > Thanks for your reply. > I was expecting the same answer as I also read the github link you sent. > I may need to try older versions of openstack in that case. do you specificaly need onos for some reason. if not i would not suggest building a production deployment with something that realiticlly is very unlikely to ever be supported again. you basically will be stuck on train with no upgrade path. > > Hrishikesh > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney wrote: > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > Hi, > > > > > > Does Openstack latest release support ONOS? > > the short answer is no > > technially upstream has never supported it because it was a big tent > > projec that was > > never an offical deliverable of the netwroking team. > > https://github.com/openstack-archive/networking-onos has been retired > > as has https://opendev.org/openstack/networking-onos. the last release > > seams to have been from train but > > even then im not sure that it was still active. > > it looks like the onos projecct move the openstack install info under teh > > obsolete paages > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per+each+OpenStack+version > > so it does not look like the intend to support openstack anymore. > > > > > > > > > > > > From rosmaita.fossdev at gmail.com Thu Aug 26 12:22:31 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 26 Aug 2021 08:22:31 -0400 Subject: [cinder] high-priority reviews this week In-Reply-To: References: Message-ID: <3d44feba-cfea-2c5b-a7d1-84e023fca6de@gmail.com> On 8/26/21 6:12 AM, Stephen Finucane wrote: > On Thu, 2021-08-26 at 00:03 -0400, Brian Rosmaita wrote: >> Hello Cinder team, >> >> As I mentioned at today's meeting, the cinderclient must be released >> next week, and this means that any Xena cinder features that we want >> supported in the Xena cinderclient need to merge into cinder first. >> We've got two cinder patches that introduce new microversions, and thus >> impact cinderclient. So please put the following patches at the top of >> your reviewing list: > > I realize that this is not tied to a cinderclient release, but can I please ask > that sqlalchemy-migrate -> alembic series [1] be included on this list also? > Milestone 3 is very close and I will not be able to continue work on this next > cycle. I'm also on holiday for two weeks starting September 6th. There are only > 8 patches remaining so let's get this over the line while I'm still around and > still have context. I endorse this 100%. Let's get the cinderclient-related stuff and Stephen's patches knocked out over the next two days, and move on to the other features next week. > > Cheers, > Stephen > > [1] https://review.opendev.org/q/topic:%2522bp/remove-sqlalchemy-migrate%2522+status:open+project:openstack/cinder > >> >> (1) "Snapshot in-use volumes without force flag" >> cinder: https://review.opendev.org/c/openstack/cinder/+/789564 >> cinderclient: (simply requires bump in MAX_VERSION, will be done in the >> release note patch) >> >> (2) "Expose volume & snapshot use_quota field" >> cinder: https://review.opendev.org/c/openstack/cinder/+/786386 >> cinderclient: >> https://review.opendev.org/c/openstack/python-cinderclient/+/787407 >> (very small patch) >> >> A slight complication is that 786386 is stacked on top of some other >> patches. On the other hand, these are all nicely done and present >> learning opportunities: >> >> - https://review.opendev.org/c/openstack/cinder/+/791240/ -- this is a >> good one to review if you're interested in how the automated tests to >> verify the request/response samples in the api-ref work >> >> - https://review.opendev.org/c/openstack/cinder/+/786383 -- relatively >> small patch with great unit test coverage >> >> - https://review.opendev.org/c/openstack/cinder/+/786384/ -- this is a >> good one if you want to get better acquainted with Cinder's use of Oslo >> Versioned Objects >> >> - https://review.opendev.org/c/openstack/cinder/+/786385 -- this is >> worth looking at to see the online data migration strategy Cinder uses >> to enable rolling upgrades >> >> - https://review.opendev.org/c/openstack/cinder/+/786386 -- this is the >> patch that introduces a new API microversion; it looks big, but a lot of >> the files are sample requests/responses for the api-ref >> >> >> Happy reviewing! >> > > From mnaser at vexxhost.com Thu Aug 26 12:35:18 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 26 Aug 2021 08:35:18 -0400 Subject: What OS image can I use for Docker Swarm in Magnum? In-Reply-To: References: <22572a58-0ee6-b009-601a-766e3b19c2b3@celati.com> <6d69dab9b94cb51d72ab7411633faa5d1caf902b.camel@redhat.com> Message-ID: We worked around those by using a version that didn’t switch to cgroupsv2 but yeah, this is an issue. On Thu, Aug 26, 2021 at 4:08 AM Ammad Syed wrote: > Hi, > > There are some bugs reported for FCOS 34 with magnum cluster, kublet > failed to start on FCOS 34 because of cgroup v2. > > https://storyboard.openstack.org/#!/story/2009045 > > > Ammad > > On Wed, Aug 25, 2021 at 6:50 PM Sean Mooney wrote: > >> On Wed, 2021-08-25 at 17:57 +0500, Ammad Syed wrote: >> > Hi Paolo, >> > >> > As far as I know, swarm clusters are unmaintained since 3 or 4 years. >> So it >> > won't work as expected. >> > >> > Most of the magnum users are using kubernetes therefore its maintained. >> > >> > For kubernetes clusters you can use fedora CoreOS 32. It works perfectly >> > fine. >> fedora 32 is no longer reciving any security or package updates as its EOL >> if you do base you deployment on fedora core os i would suggest using a >> more recent version. >> im not sure if will work with magnuma but i dont think we really should >> recommend using an unsupported >> OS for any new deployments. >> >> keep im mind that fedroa support policy is 2 release +1 month for hte >> base os. >> that tipically means its only supported for 13 months >> fedora 32 becamue EOL on 2021-05-25 3 months ago >> >> ideally if you are using fedora core os you would start form the most >> recent release and subscipe to t the stabel update >> stream https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/ >> the cloud image can be retrived here >> https://getfedora.org/coreos/download?tab=cloud_operators&stream=stable >> >> and the general openstack instuction are found here >> https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-openstack/ >> thse are really not targeted at magnum but rater makeing fedora core os >> avaiabel for other vms however you likely should >> use those images if they are compatibale with magnum. >> >> >> >> > >> > You can use below link for installation. >> > >> > >> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=10 >> > >> > Ammad >> > >> > On Wed, Aug 25, 2021 at 5:25 PM Paolo Celati wrote: >> > >> > > Hi, >> > > >> > > I'm looking to set up Docker Swarm using Openstack Magnum and I >> > > noticed the user guide for magnum lists only Fedora Atomic as >> > > supported. If I'm not mistaken though Atomic has been discontinued >> for >> > > a while now, so I'm wondering what you use for this use case. Can I >> use >> > > Fedora CoreOS instead, and if so are there any gotchas I should know >> as >> > > a first time Magnum user? >> > > >> > > >> > > Thanks in advance, >> > > >> > > Paolo >> > > >> > > >> > >> >> >> > > -- > Regards, > > > Syed Ammad Ali > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello at dincercelik.com Thu Aug 26 14:23:37 2021 From: hello at dincercelik.com (Dincer Celik) Date: Thu, 26 Aug 2021 17:23:37 +0300 Subject: [kolla] PTL non-candidacy In-Reply-To: References: Message-ID: <4520600B-EDA6-4E5E-9AC0-B2D6474360C8@dincercelik.com> Thank you for all your work Mark. You did an amazing job. > On 18 Aug 2021, at 11:17, 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 > From hello at dincercelik.com Thu Aug 26 14:33:26 2021 From: hello at dincercelik.com (Dincer Celik) Date: Thu, 26 Aug 2021 17:33:26 +0300 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: Thank you for all your work and volunteering Michal. > On 18 Aug 2021, at 12:16, Michał Nasiadka wrote: > > 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 gaetan.trellu at incloudus.com Thu Aug 26 14:47:57 2021 From: gaetan.trellu at incloudus.com (=?ISO-8859-1?Q?Ga=EBtan_Trellu?=) Date: Thu, 26 Aug 2021 08:47:57 -0600 Subject: [kolla] PTL non-candidacy In-Reply-To: <4520600B-EDA6-4E5E-9AC0-B2D6474360C8@dincercelik.com> Message-ID: <6cc207b0-171f-47be-85c9-e81b8a837b6e@email.android.com> An HTML attachment was scrubbed... URL: From christophe.sauthier at objectif-libre.com Thu Aug 26 15:55:35 2021 From: christophe.sauthier at objectif-libre.com (Christophe Sauthier) Date: Thu, 26 Aug 2021 11:55:35 -0400 Subject: [election][cloudkitty] PTL Candidacy for Yoga In-Reply-To: References: Message-ID: Thanks for continuing the development on Cloudkitty ! Christophe On Tue, Aug 24, 2021 at 6:46 AM Rafael Weingärtner < rafaelweingartner at gmail.com> wrote: > Hello Cloudkitters, > > I would like to nominate myself to serve as Cloudkitty PTL for the Yoga > cycle. > I've been working with OpenStack since 2018 and contributing to Cloudkitty > since May 2019. > > I hope that we can continue to achieve goals together, making CloudKitty > better and more robust. We should also aim to grow our contributor base and > continue to spread the word about CloudKitty (blog posts, social media, > etc). > > > Features that I think we should aim for during the next cycle: the > reprocessing API ( > https://review.opendev.org/c/openstack/cloudkitty/+/799207), and Storage > state status (https://review.opendev.org/c/openstack/cloudkitty/+/777442), > both of which are already proposed and in the review process. > > Best regards, > > -- > Rafael Weingärtner > -- ---- Christophe Sauthier Directeur Général Objectif Libre : Au service de votre Cloud +33 (0) 6 16 98 63 96 | christophe.sauthier at objectif-libre.com https://www.objectif-libre.com | @objectiflibre Recevez la Pause Cloud Et DevOps : https://olib.re/abo-pause -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Thu Aug 26 03:59:14 2021 From: tonykarera at gmail.com (Karera Tony) Date: Thu, 26 Aug 2021 05:59:14 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Dear Sir, You are right. I am getting this error kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? Regards Tony Karera On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar wrote: > I’d check the logs under /var/log/heat-config. > > Sent from my iPhone > > On 25 Aug 2021, at 19:39, Karera Tony wrote: > >  > DeaR Ammad, > > I was able to make the communication work and the Worker nodes were > created as well but the cluster failed. > > I logged in to the master node and there was no error but below are the > error when I run systemctl status heat-container-agent on the worker noed. > > Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: > /var/lib/os-collect-config/local-data not found. Skipping > Regards > > Tony Karera > > > > > On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed wrote: > >> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >> reachable from master and worker nodes. >> >> You can use below guide for the reference as well. >> >> >> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >> >> Ammad >> >> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >> wrote: >> >>> Hello Ammad, >>> >>> I have deployed using the given image but I think there is an issue with >>> keystone as per the screen shot below when I checked the master node's >>> heat-container-agent status >>> >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>> wrote: >>> >>>> Hello Ammad, >>>> >>>> I actually first used that one and it was also getting stuck. >>>> >>>> I will try this one again and update you with the Logs though. >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>> wrote: >>>> >>>>> It seems from the logs that you are using fedora atomic. Can you try >>>>> with FCOS 32 image. >>>>> >>>>> >>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>> >>>>> Ammad >>>>> >>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>>> wrote: >>>>> >>>>>> Hello Sir, >>>>>> >>>>>> Attached is the Log file >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>>> wrote: >>>>>> >>>>>>> Hi Karera, >>>>>>> >>>>>>> Can you share us the full log file. >>>>>>> >>>>>>> Ammad >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Guys, >>>>>>>> >>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>> keeps appearing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>> >>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Ammad >>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>> >> >>>>>>>>> >> Hello Ammad, >>>>>>>>> >> >>>>>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>>>>> directory >>>>>>>>> >> >>>>>>>>> >> Regards >>>>>>>>> >> >>>>>>>>> >> Tony Karera >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>> >>> >>>>>>>>> >>> Hi Karera, >>>>>>>>> >>> >>>>>>>>> >>> Login to master node and check the logs of heat agent in var >>>>>>>>> log. There must be something the cluster is stucking somewhere in creating. >>>>>>>>> >>> >>>>>>>>> >>> Ammad >>>>>>>>> >>> >>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> Hello Ammad, >>>>>>>>> >>>> >>>>>>>>> >>>> I had done as explained and it worked upto a certain point. >>>>>>>>> The master node was created but the cluster remained in Creation in >>>>>>>>> progress for over an hour and failed with error below >>>>>>>>> >>>> >>>>>>>>> >>>> Stack Faults >>>>>>>>> >>>> as follows: >>>>>>>>> >>>> default-master >>>>>>>>> >>>> Timed out >>>>>>>>> >>>> default-worker >>>>>>>>> >>>> Timed out >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Regards >>>>>>>>> >>>> >>>>>>>>> >>>> Tony Karera >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Hi Tony, >>>>>>>>> >>>>> >>>>>>>>> >>>>> You can try by creating your private vxlan network prior to >>>>>>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>>>> >>>>> >>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>> >>>>> >>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Ammad >>>>>>>>> >>>>> >>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy >>>>>>>>> it, It creates a fixed network using vlan which I am not using for internal >>>>>>>>> networks. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>>>>> creation, It fails. Is there a trick around this ? >>>>>>>>> >>>>>> Regards >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Tony Karera >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> 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 < >>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>> command look like? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>> >>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> -- >>>>>>>>> >>>>> Regards, >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> -- >>>>>>>>> >>> Regards, >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Syed Ammad Ali >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > Regards, >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Syed Ammad Ali >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mohammed Naser >>>>>>>>> VEXXHOST, Inc. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Syed Ammad Ali >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >>>>> >>>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Thu Aug 26 05:14:07 2021 From: tonykarera at gmail.com (Karera Tony) Date: Thu, 26 Aug 2021 07:14:07 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Hello Guys, Attached are the two logs from the /var/log/heat-config/heat-config-script directory Regards Tony Karera On Thu, Aug 26, 2021 at 5:59 AM Karera Tony wrote: > Dear Sir, > > You are right. > > I am getting this error > > kubectl get --raw=/healthz > The connection to the server localhost:8080 was refused - did you specify > the right host or port? > > > Regards > > Tony Karera > > > > > On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar > wrote: > >> I’d check the logs under /var/log/heat-config. >> >> Sent from my iPhone >> >> On 25 Aug 2021, at 19:39, Karera Tony wrote: >> >>  >> DeaR Ammad, >> >> I was able to make the communication work and the Worker nodes were >> created as well but the cluster failed. >> >> I logged in to the master node and there was no error but below are the >> error when I run systemctl status heat-container-agent on the worker noed. >> >> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >> /var/lib/os-collect-config/local-data not found. Skipping >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >> wrote: >> >>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>> reachable from master and worker nodes. >>> >>> You can use below guide for the reference as well. >>> >>> >>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>> >>> Ammad >>> >>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>> wrote: >>> >>>> Hello Ammad, >>>> >>>> I have deployed using the given image but I think there is an issue >>>> with keystone as per the screen shot below when I checked the master node's >>>> heat-container-agent status >>>> >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>> wrote: >>>> >>>>> Hello Ammad, >>>>> >>>>> I actually first used that one and it was also getting stuck. >>>>> >>>>> I will try this one again and update you with the Logs though. >>>>> >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>> wrote: >>>>> >>>>>> It seems from the logs that you are using fedora atomic. Can you try >>>>>> with FCOS 32 image. >>>>>> >>>>>> >>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>> >>>>>> Ammad >>>>>> >>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>>>> wrote: >>>>>> >>>>>>> Hello Sir, >>>>>>> >>>>>>> Attached is the Log file >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Karera, >>>>>>>> >>>>>>>> Can you share us the full log file. >>>>>>>> >>>>>>>> Ammad >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello Guys, >>>>>>>>> >>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>> keeps appearing. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Tony Karera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>> >>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>> >>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>> status. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Ammad >>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>> >> >>>>>>>>>> >> Hello Ammad, >>>>>>>>>> >> >>>>>>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>>>>>> directory >>>>>>>>>> >> >>>>>>>>>> >> Regards >>>>>>>>>> >> >>>>>>>>>> >> Tony Karera >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>> >>> >>>>>>>>>> >>> Hi Karera, >>>>>>>>>> >>> >>>>>>>>>> >>> Login to master node and check the logs of heat agent in var >>>>>>>>>> log. There must be something the cluster is stucking somewhere in creating. >>>>>>>>>> >>> >>>>>>>>>> >>> Ammad >>>>>>>>>> >>> >>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>> >>>> >>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>> >>>> >>>>>>>>>> >>>> I had done as explained and it worked upto a certain point. >>>>>>>>>> The master node was created but the cluster remained in Creation in >>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>> >>>> >>>>>>>>>> >>>> Stack Faults >>>>>>>>>> >>>> as follows: >>>>>>>>>> >>>> default-master >>>>>>>>>> >>>> Timed out >>>>>>>>>> >>>> default-worker >>>>>>>>>> >>>> Timed out >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> Regards >>>>>>>>>> >>>> >>>>>>>>>> >>>> Tony Karera >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> You can try by creating your private vxlan network prior to >>>>>>>>>> deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Ammad >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy >>>>>>>>>> it, It creates a fixed network using vlan which I am not using for internal >>>>>>>>>> networks. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>>>>>> creation, It fails. Is there a trick around this ? >>>>>>>>>> >>>>>> Regards >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> 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 < >>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>> command look like? >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>> >>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> -- >>>>>>>>>> >>>>> Regards, >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> -- >>>>>>>>>> >>> Regards, >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>> > >>>>>>>>>> > -- >>>>>>>>>> > Regards, >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Syed Ammad Ali >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mohammed Naser >>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> >>>>>>>> Syed Ammad Ali >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> Syed Ammad Ali >>>>>> >>>>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log Type: application/octet-stream Size: 11011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log Type: application/octet-stream Size: 1614278 bytes Desc: not available URL: From bharat at stackhpc.com Thu Aug 26 05:53:04 2021 From: bharat at stackhpc.com (Bharat Kunwar) Date: Thu, 26 Aug 2021 06:53:04 +0100 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: I assume these are from the master nodes? Can you share the logs shortly after creation rather than when it times out? I think there is some missing logs from the top. Sent from my iPhone > On 26 Aug 2021, at 06:14, Karera Tony wrote: > >  > Hello Guys, > > Attached are the two logs from the /var/log/heat-config/heat-config-script directory > Regards > > Tony Karera > > > > >> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony wrote: >> Dear Sir, >> >> You are right. >> >> I am getting this error >> >> kubectl get --raw=/healthz >> The connection to the server localhost:8080 was refused - did you specify the right host or port? >> >> >> Regards >> >> Tony Karera >> >> >> >> >>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar wrote: >>> I’d check the logs under /var/log/heat-config. >>> >>> Sent from my iPhone >>> >>>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>>> >>>>  >>>> DeaR Ammad, >>>> >>>> I was able to make the communication work and the Worker nodes were created as well but the cluster failed. >>>> >>>> I logged in to the master node and there was no error but below are the error when I run systemctl status heat-container-agent on the worker noed. >>>> >>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: /var/lib/os-collect-config/local-data not found. Skipping >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed wrote: >>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be reachable from master and worker nodes. >>>>> >>>>> You can use below guide for the reference as well. >>>>> >>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>> >>>>> Ammad >>>>> >>>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony wrote: >>>>>> Hello Ammad, >>>>>> >>>>>> I have deployed using the given image but I think there is an issue with keystone as per the screen shot below when I checked the master node's heat-container-agent status >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony wrote: >>>>>>> Hello Ammad, >>>>>>> >>>>>>> I actually first used that one and it was also getting stuck. >>>>>>> >>>>>>> I will try this one again and update you with the Logs though. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed wrote: >>>>>>>> It seems from the logs that you are using fedora atomic. Can you try with FCOS 32 image. >>>>>>>> >>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>> >>>>>>>> Ammad >>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony wrote: >>>>>>>>> Hello Sir, >>>>>>>>> >>>>>>>>> Attached is the Log file >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Tony Karera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed wrote: >>>>>>>>>> Hi Karera, >>>>>>>>>> >>>>>>>>>> Can you share us the full log file. >>>>>>>>>> >>>>>>>>>> Ammad >>>>>>>>>> >>>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony wrote: >>>>>>>>>>> Hello Guys, >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much information in the log file indicating a failure apart from the log that keeps appearing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Tony Karera >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser wrote: >>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service status. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Ammad >>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>> >> >>>>>>>>>>>> >> There is no directory or log relevant to heat in the /var/log directory >>>>>>>>>>>> >> >>>>>>>>>>>> >> Regards >>>>>>>>>>>> >> >>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Login to master node and check the logs of heat agent in var log. There must be something the cluster is stucking somewhere in creating. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Ammad >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain point. The master node was created but the cluster remained in Creation in progress for over an hour and failed with error below >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>> >>>> default-master >>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Regards >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed wrote: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> You can try by creating your private vxlan network prior to deployment of cluster and explicitly create your cluster in vxlan network. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony wrote: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy it, It creates a fixed network using vlan which I am not using for internal networks. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong wrote: >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> 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. >>>>>>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> -- >>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> -- >>>>>>>>>>>> >>> Regards, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>> > >>>>>>>>>>>> > -- >>>>>>>>>>>> > Regards, >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Syed Ammad Ali >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> >>>>>>>> Syed Ammad Ali >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali > > <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> > <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Thu Aug 26 06:04:35 2021 From: kkchn.in at gmail.com (KK CHN) Date: Thu, 26 Aug 2021 11:34:35 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: <0670B960225633449A24709C291A525251C86EC8@COM03.performair.local> References: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> <0670B960225633449A24709C291A525251C86EC8@COM03.performair.local> Message-ID: A bit of confusion reading this document for Windows VMs to OpenStack. It's quite old. But I need to clarify with list members. https://superuser.openstack.org/articles/how-to-migrate-from-vmware-and-hyper-v-to-openstack/ Is this virtIO driver injection methods still relevant for migrating Windows VMs from Other hypervisors ( in my case HyperV) to OpenStack ( qemu KVM, USSURI version ). On Wed, Aug 25, 2021 at 9:12 PM wrote: > Kris; > > > > This shouldn’t be all that much more difficult than Linux, nor that much > harder than a single-disk Windows VM. > > Thanks: I am going to follow as you guided here. But I came across the above link a few days back while referring to online documents, Is this VirtIO injection steps necessary nowadays( as the article on the link refers to year 2015 or so. Kindly enlighten me about the relevance of VirtIO injection now also if applicable. But for Single disk WIndows VM importing to my OpenStack, I did not do the VirtIO injection steps:) . Am I doing wrong here ? I am able to get the Single disk Windows VM imported to OpenStack and the instance running and able to login with administrator credentials. > > I would start by disabling the SQL service, as the OpenStack instance will > boot once before you can add the data disks (at least it does for me when > using Horizon). > > > > Export the disks, convert then, and import them, all as you normally > would. Create the instance, as you normally would. The instance will > start; shut it back down. Attach the additional volumes, and start the > instance back up. > > > > It would be nice to have an option to not start the instance after > creation. > > > > You could also investigate the “openstack server create” command; it has a > --volume argument that you may be able to pass more than once, though I > suspect not. > > > > 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:* Tuesday, August 24, 2021 11:19 PM > *To:* openstack-discuss at lists.openstack.org > *Subject:* Re: Windows2012 VM image importing and Instance Launch Failure > > > > Thank you all. > > > > I am able to get the Single disk Windows VM exported from HyperV and > imported to OpenStack(Ussuri, Glance and Qemu KVM ) Instance launched and > its showing the status running in the PowerState Tab of Horizon dashboard. > > > > (need to check with the administrator user to login and confirm the VM is > working as expected . ) > > > > My second phase : I need to perform importing multiple disk > Windows VM to my OpenStack setup . > > > > ( For single disk Windows vhdx file, I 've converted it to qcow2 file and > imported to OpenStack as the steps I posted in my previous emails. ) > > > > Now how can I import Multiple disk Windows VM to OpenStack. > > > > First Step is to convert the vhdx files exported from HyperV to qcow2 > files. > > > > After this step , what steps need to be performed to bring a multi > disk Windows VM to OpeStack ? > > > > For Eg: I have a Windows VM > > > > 1. with Application server 1TB single disk image exported from hyperV. > This I can import to my OpenStack setup with the steps I followed in my > earlier emails as it is a single disk image. > > > > > > 2. A Database server for the above application with 700 GB in multiple > disks. ( 100 and 600 GB disks images exported from HyperV and in vhdx > format for DB server) > > > > How to bring this server imported to my OpeStack setup (ussuri, glance > and QEMU KVM). As this is from Windows HyperV I am new to multidisk > environment from Windows. > > ( for Linux VMs exported from oVirt(RHVM) I am able to import multidisk > VMs to OpenStack as they are in LVM and I have to mount it with VG name and > adding entries in /etc/fstab file ) > > > > But in Windows multi disks how to perform this ? what steps I have to > perform to import this to OpenStack. Any hints or suggestions most > welcome.. > > > > Kris > > > > > > On Tue, Aug 24, 2021 at 1:40 PM Eugen Block wrote: > > Of course you need a running nova-conductor, how did you launch VMs before? > > > Zitat von KK CHN : > > > 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 tonykarera at gmail.com Thu Aug 26 06:30:29 2021 From: tonykarera at gmail.com (Karera Tony) Date: Thu, 26 Aug 2021 08:30:29 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Here is the beginning of the Log Starting to run kube-apiserver-to-kubelet-role + echo 'Waiting for Kubernetes API...' Waiting for Kubernetes API... ++ kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? + '[' ok = '' ']' Regards Tony Karera On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar wrote: > I assume these are from the master nodes? Can you share the logs shortly > after creation rather than when it times out? I think there is some missing > logs from the top. > > Sent from my iPhone > > On 26 Aug 2021, at 06:14, Karera Tony wrote: > >  > Hello Guys, > > Attached are the two logs from the /var/log/heat-config/heat-config-script > directory > Regards > > Tony Karera > > > > > On Thu, Aug 26, 2021 at 5:59 AM Karera Tony wrote: > >> Dear Sir, >> >> You are right. >> >> I am getting this error >> >> kubectl get --raw=/healthz >> The connection to the server localhost:8080 was refused - did you specify >> the right host or port? >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >> wrote: >> >>> I’d check the logs under /var/log/heat-config. >>> >>> Sent from my iPhone >>> >>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>> >>>  >>> DeaR Ammad, >>> >>> I was able to make the communication work and the Worker nodes were >>> created as well but the cluster failed. >>> >>> I logged in to the master node and there was no error but below are the >>> error when I run systemctl status heat-container-agent on the worker noed. >>> >>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>> /var/lib/os-collect-config/local-data not found. Skipping >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>> wrote: >>> >>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>> reachable from master and worker nodes. >>>> >>>> You can use below guide for the reference as well. >>>> >>>> >>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>> >>>> Ammad >>>> >>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>> wrote: >>>> >>>>> Hello Ammad, >>>>> >>>>> I have deployed using the given image but I think there is an issue >>>>> with keystone as per the screen shot below when I checked the master node's >>>>> heat-container-agent status >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>> wrote: >>>>> >>>>>> Hello Ammad, >>>>>> >>>>>> I actually first used that one and it was also getting stuck. >>>>>> >>>>>> I will try this one again and update you with the Logs though. >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>>> wrote: >>>>>> >>>>>>> It seems from the logs that you are using fedora atomic. Can you try >>>>>>> with FCOS 32 image. >>>>>>> >>>>>>> >>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>> >>>>>>> Ammad >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Sir, >>>>>>>> >>>>>>>> Attached is the Log file >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Karera, >>>>>>>>> >>>>>>>>> Can you share us the full log file. >>>>>>>>> >>>>>>>>> Ammad >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello Guys, >>>>>>>>>> >>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>> keeps appearing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Tony Karera >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>> >>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>> status. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Ammad >>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>> >> >>>>>>>>>>> >> There is no directory or log relevant to heat in the /var/log >>>>>>>>>>> directory >>>>>>>>>>> >> >>>>>>>>>>> >> Regards >>>>>>>>>>> >> >>>>>>>>>>> >> Tony Karera >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>> >>> >>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>> >>> >>>>>>>>>>> >>> Login to master node and check the logs of heat agent in var >>>>>>>>>>> log. There must be something the cluster is stucking somewhere in creating. >>>>>>>>>>> >>> >>>>>>>>>>> >>> Ammad >>>>>>>>>>> >>> >>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> I had done as explained and it worked upto a certain point. >>>>>>>>>>> The master node was created but the cluster remained in Creation in >>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>> >>>> as follows: >>>>>>>>>>> >>>> default-master >>>>>>>>>>> >>>> Timed out >>>>>>>>>>> >>>> default-worker >>>>>>>>>>> >>>> Timed out >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Regards >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> You can try by creating your private vxlan network prior >>>>>>>>>>> to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>> network. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Ammad >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I deploy >>>>>>>>>>> it, It creates a fixed network using vlan which I am not using for internal >>>>>>>>>>> networks. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the cluster >>>>>>>>>>> creation, It fails. Is there a trick around this ? >>>>>>>>>>> >>>>>> Regards >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>>> command look like? >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> -- >>>>>>>>>>> >>>>> Regards, >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> -- >>>>>>>>>>> >>> Regards, >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>> > >>>>>>>>>>> > -- >>>>>>>>>>> > Regards, >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Mohammed Naser >>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Syed Ammad Ali >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Syed Ammad Ali >>>>>>> >>>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> Syed Ammad Ali >>>> >>> > <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> > > <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Thu Aug 26 06:39:45 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 14:39:45 +0800 Subject: why cannot launch the instance ? In-Reply-To: <001501d79a3b$24b33030$6e199090$@163.com> References: <001501d79a3b$24b33030$6e199090$@163.com> Message-ID: <002701d79a45$2935c690$7ba153b0$@163.com> Why ?? From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Thursday, August 26, 2021 1:28 PM To: 'openstack-discuss' Subject: why cannot launch the instance ? After the success deploy, I try to create a instance and launch it. But it failed. The error is : Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Code 500 Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Created Aug. 25, 2021, 3:23 p.m. Why ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33647 bytes Desc: not available URL: From sz_cuitao at 163.com Thu Aug 26 06:48:01 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Thu, 26 Aug 2021 14:48:01 +0800 Subject: why cannot launch the instance ? In-Reply-To: <001501d79a3b$24b33030$6e199090$@163.com> References: <001501d79a3b$24b33030$6e199090$@163.com> Message-ID: <003801d79a46$5193ade0$f4bb09a0$@163.com> I try again, it shows that I cannot stat. From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Thursday, August 26, 2021 1:28 PM To: 'openstack-discuss' Subject: why cannot launch the instance ? After the success deploy, I try to create a instance and launch it. But it failed. The error is : Message Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Code 500 Details Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 665, in build_instances raise exception.MaxRetriesExceeded(reason=msg) nova.exception.MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance b238edf6-093b-41ce-bd59-a349f8e8fa12. Created Aug. 25, 2021, 3:23 p.m. Why ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2021-08-26 144649.jpg Type: image/jpeg Size: 70309 bytes Desc: not available URL: From syedammad83 at gmail.com Thu Aug 26 07:55:48 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Thu, 26 Aug 2021 12:55:48 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: The output in logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd is incomplete. There should be the installation and configuration of many other things that are missing. Also it looks that hyperkube is not installed. Can you check the response of "podman ps" command on master nodes. Ammad On Thu, Aug 26, 2021 at 11:30 AM Karera Tony wrote: > Here is the beginning of the Log > > Starting to run kube-apiserver-to-kubelet-role > + echo 'Waiting for Kubernetes API...' > Waiting for Kubernetes API... > ++ kubectl get --raw=/healthz > The connection to the server localhost:8080 was refused - did you specify > the right host or port? > + '[' ok = '' ']' > > > Regards > > Tony Karera > > > > > On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar wrote: > >> I assume these are from the master nodes? Can you share the logs shortly >> after creation rather than when it times out? I think there is some missing >> logs from the top. >> >> Sent from my iPhone >> >> On 26 Aug 2021, at 06:14, Karera Tony wrote: >> >>  >> Hello Guys, >> >> Attached are the two logs from the >> /var/log/heat-config/heat-config-script directory >> Regards >> >> Tony Karera >> >> >> >> >> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony wrote: >> >>> Dear Sir, >>> >>> You are right. >>> >>> I am getting this error >>> >>> kubectl get --raw=/healthz >>> The connection to the server localhost:8080 was refused - did you >>> specify the right host or port? >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >>> wrote: >>> >>>> I’d check the logs under /var/log/heat-config. >>>> >>>> Sent from my iPhone >>>> >>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>> >>>>  >>>> DeaR Ammad, >>>> >>>> I was able to make the communication work and the Worker nodes were >>>> created as well but the cluster failed. >>>> >>>> I logged in to the master node and there was no error but below are the >>>> error when I run systemctl status heat-container-agent on the worker noed. >>>> >>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>> /var/lib/os-collect-config/local-data not found. Skipping >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>>> wrote: >>>> >>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>>> reachable from master and worker nodes. >>>>> >>>>> You can use below guide for the reference as well. >>>>> >>>>> >>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>> >>>>> Ammad >>>>> >>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>>> wrote: >>>>> >>>>>> Hello Ammad, >>>>>> >>>>>> I have deployed using the given image but I think there is an issue >>>>>> with keystone as per the screen shot below when I checked the master node's >>>>>> heat-container-agent status >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>>> wrote: >>>>>> >>>>>>> Hello Ammad, >>>>>>> >>>>>>> I actually first used that one and it was also getting stuck. >>>>>>> >>>>>>> I will try this one again and update you with the Logs though. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>>>> wrote: >>>>>>> >>>>>>>> It seems from the logs that you are using fedora atomic. Can you >>>>>>>> try with FCOS 32 image. >>>>>>>> >>>>>>>> >>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>> >>>>>>>> Ammad >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello Sir, >>>>>>>>> >>>>>>>>> Attached is the Log file >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Tony Karera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Karera, >>>>>>>>>> >>>>>>>>>> Can you share us the full log file. >>>>>>>>>> >>>>>>>>>> Ammad >>>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hello Guys, >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>>> keeps appearing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Tony Karera >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>>> status. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Ammad >>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>> >> >>>>>>>>>>>> >> There is no directory or log relevant to heat in the >>>>>>>>>>>> /var/log directory >>>>>>>>>>>> >> >>>>>>>>>>>> >> Regards >>>>>>>>>>>> >> >>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Login to master node and check the logs of heat agent in >>>>>>>>>>>> var log. There must be something the cluster is stucking somewhere in >>>>>>>>>>>> creating. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Ammad >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain >>>>>>>>>>>> point. The master node was created but the cluster remained in Creation in >>>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>> >>>> default-master >>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Regards >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> You can try by creating your private vxlan network prior >>>>>>>>>>>> to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>>> network. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I >>>>>>>>>>>> deploy it, It creates a fixed network using vlan which I am not using for >>>>>>>>>>>> internal networks. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the >>>>>>>>>>>> cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>>>> command look like? >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> -- >>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> -- >>>>>>>>>>>> >>> Regards, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>> > >>>>>>>>>>>> > -- >>>>>>>>>>>> > Regards, >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Syed Ammad Ali >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> >>>>>>>> Syed Ammad Ali >>>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >>>>> >>>> >> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >> >> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> >> >> -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Thu Aug 26 19:26:46 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Thu, 26 Aug 2021 12:26:46 -0700 Subject: [devstack][neutron][manila] Instances having trouble getting to external network with OVN In-Reply-To: References: Message-ID: On Tue, Aug 24, 2021 at 4:24 PM Clark Boylan wrote: > On Tue, Aug 24, 2021, at 11:21 AM, Goutham Pacha Ravi wrote: > > Hi, > > > > Bubbling up this issue - I reported a launchpad bug with some more > > debug information: > > https://bugs.launchpad.net/bugs/1939627 > > > > I’m confused how/why only the Manila gates are hitting this issue. If > > you’re reading - do you have any tests elsewhere that setup a nova > > instance on a devstack and ping/communicate with the internet/outside > > world? If yes, I’d love to compare configuration with your setup. > > It has been a while since I looked at this stuff and the OVN switch may > have changed it, but we have historically intentionally avoided external > connectivity for the nested devstack cloud in upstream CI. Instead we > expect the test jobs to be self contained. On multinode jobs we set up an > entire L2 network with very simple L3 routing that is independent of the > host system networking with vxlan. This allows tempest to talk to the test > instances on the nested cloud. But those nested cloud instances cannot get > off the instance. This is important because it helps keep things like dhcp > requests from leaking out into the world. > Even if you configured floating IPs on the inner instances those IPs > wouldn't be routable to the host instance in the clouds that we host jobs > in. To make this work without a bunch of support from the hosting > environment you would need to NAT between the host instances IP and inner > nested devstack instances so that traffic exiting the test instances had a > path to the outside world that can receive the return traffic. > Thanks Clark; the tests we're running are either outside CI - i.e., with local devstack, or on third party CI systems where the guest VMs would need to access storage that's external to the devstack. These are tempest tests that have no reason to reach out to the external world. I didn't know the reason behind this design, so this insight is useful to me! > > In https://bugs.launchpad.net/bugs/1939627 you are creating an external > network and floating IPs but once that traffic leaves the host system there > must be a return path for any responses, and I suspect that is what is > missing? It is odd that this would coincide with the OVN change. Maybe IP > ranges were updated with the OVN change and any hosting support that > enabled routing of those IPs is no longer valid as a result? I was scratching my head and reading the OVN integration code as well - but neutron internals wasn't my strong suit. slaweq and ralonsoh were able to root-cause this to missing NAT rule/s in the devstack ovn-agent setup. \o/ > > > > > Thank you so much for your help, > > > > Goutham > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.moravec at wildcardcorp.com Thu Aug 26 22:29:26 2021 From: justin.moravec at wildcardcorp.com (Justin Moravec) Date: Thu, 26 Aug 2021 17:29:26 -0500 Subject: Kolla-ansible new controller node Message-ID: <46B73193-A6C1-4F20-85F3-FB5137F47AF9@wildcardcorp.com> Deploying a new controller node to the environment, i get stuck at keystone : Waiting for Keystone SSH port to be UP. It looks like there isn't even an attempt to start the keystone-ssh container before this. Steps to reproduce kolla-ansible -i multinode bootstrap-servers --limit kolla-ansible -i multinode prechecks kolla-ansible -i multinode deploy Using kolla-ansible to deploy. Ussuri Deployment. Ubuntu 18.04 server environment. Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Fri Aug 27 02:16:11 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Thu, 26 Aug 2021 19:16:11 -0700 Subject: [manila] Propose haixin to manila-core In-Reply-To: References: Message-ID: On Wed, Aug 11, 2021 at 2:59 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 for the votes of confidence everyone - welcome to the maintainer squad Haixin! > > > 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 eduardo.experimental at gmail.com Fri Aug 27 03:36:54 2021 From: eduardo.experimental at gmail.com (Eduardo Santos) Date: Fri, 27 Aug 2021 03:36:54 +0000 Subject: [manila] Propose haixin to manila-core In-Reply-To: References: Message-ID: +1 Congrats again haixin! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrishikesh.karanjikar at gmail.com Fri Aug 27 05:18:10 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Fri, 27 Aug 2021 10:48:10 +0530 Subject: Support for ONOS In-Reply-To: References: Message-ID: Hi Sean, I am new to this domain. My use case is simple, I have a node that runs OvS and I want to manage the flows remotely using an SDN controller. Initially I tried with ODL but it does not have a Web UI like ONOS has. So I was using ONOS. I am not sure if Neutron would do the same. If it is possible then I will not need any other SDN controller. I am not doing any deployment yet. Thanks, Hrishikesh On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney wrote: > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > Hi Sean, > > > > Thanks for your reply. > > I was expecting the same answer as I also read the github link you sent. > > I may need to try older versions of openstack in that case. > do you specificaly need onos for some reason. > > if not i would not suggest building a production deployment with something > that realiticlly is > very unlikely to ever be supported again. you basically will be stuck on > train with no upgrade > path. > > > > Hrishikesh > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney wrote: > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > Hi, > > > > > > > > Does Openstack latest release support ONOS? > > > the short answer is no > > > technially upstream has never supported it because it was a big tent > > > projec that was > > > never an offical deliverable of the netwroking team. > > > https://github.com/openstack-archive/networking-onos has been retired > > > as has https://opendev.org/openstack/networking-onos. the last release > > > seams to have been from train but > > > even then im not sure that it was still active. > > > it looks like the onos projecct move the openstack install info under > teh > > > obsolete paages > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per+each+OpenStack+version > > > so it does not look like the intend to support openstack anymore. > > > > > > > > > > > > > > > > > > > > > -- Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Fri Aug 27 06:48:26 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 27 Aug 2021 08:48:26 +0200 Subject: Support for ONOS In-Reply-To: References: Message-ID: <6274919.X2OcgljGYc@p1> Hi, On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar wrote: > Hi Sean, > > I am new to this domain. > My use case is simple, > > I have a node that runs OvS and I want to manage the flows remotely using > an SDN controller. > Initially I tried with ODL but it does not have a Web UI like ONOS has. > So I was using ONOS. > I am not sure if Neutron would do the same. If it is possible then I will > not need any other SDN controller. Neutron is generally providing connectivity for Your VMs/routers/etc and it may use different backend. If You will use e.g. ML2 plugin with OVN backend, Neutron will configure OVN and OVN will then configure flows in OVS on the nodes to achieve that. But if You are looking for a tool which will allow You to see OpenFlow rules on each node, and manipulate them with some GUI, then Neutron is not for You. It don't have such functionality. > > I am not doing any deployment yet. > > Thanks, > Hrishikesh > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney wrote: > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > Hi Sean, > > > > > > Thanks for your reply. > > > I was expecting the same answer as I also read the github link you sent. > > > I may need to try older versions of openstack in that case. > > > > do you specificaly need onos for some reason. > > > > if not i would not suggest building a production deployment with something > > that realiticlly is > > very unlikely to ever be supported again. you basically will be stuck on > > train with no upgrade > > path. > > > > > Hrishikesh > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney wrote: > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > > Hi, > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > the short answer is no > > > > technially upstream has never supported it because it was a big tent > > > > projec that was > > > > never an offical deliverable of the netwroking team. > > > > https://github.com/openstack-archive/networking-onos has been retired > > > > as has https://opendev.org/openstack/networking-onos. the last release > > > > seams to have been from train but > > > > even then im not sure that it was still active. > > > > it looks like the onos projecct move the openstack install info under > > > > teh > > > > > > obsolete paages > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > +each+OpenStack+version> > > > > so it does not look like the intend to support openstack anymore. -- 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 hrishikesh.karanjikar at gmail.com Fri Aug 27 07:33:23 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Fri, 27 Aug 2021 13:03:23 +0530 Subject: Support for ONOS In-Reply-To: <6274919.X2OcgljGYc@p1> References: <6274919.X2OcgljGYc@p1> Message-ID: Hi Slawek, Thanks for your reply. Can you guide Which SDN controller is best and supported in Netron via ML2 plugin/driver. Thanks, Hrishikesh On Fri, Aug 27, 2021 at 12:18 PM Slawek Kaplonski wrote: > Hi, > > On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar wrote: > > Hi Sean, > > > > I am new to this domain. > > My use case is simple, > > > > I have a node that runs OvS and I want to manage the flows remotely using > > an SDN controller. > > Initially I tried with ODL but it does not have a Web UI like ONOS has. > > So I was using ONOS. > > I am not sure if Neutron would do the same. If it is possible then I will > > not need any other SDN controller. > > Neutron is generally providing connectivity for Your VMs/routers/etc and > it > may use different backend. If You will use e.g. ML2 plugin with OVN > backend, > Neutron will configure OVN and OVN will then configure flows in OVS on the > nodes > to achieve that. > But if You are looking for a tool which will allow You to see OpenFlow > rules > on each node, and manipulate them with some GUI, then Neutron is not for > You. > It don't have such functionality. > > > > > I am not doing any deployment yet. > > > > Thanks, > > Hrishikesh > > > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney wrote: > > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > > Hi Sean, > > > > > > > > Thanks for your reply. > > > > I was expecting the same answer as I also read the github link you > sent. > > > > I may need to try older versions of openstack in that case. > > > > > > do you specificaly need onos for some reason. > > > > > > if not i would not suggest building a production deployment with > something > > > that realiticlly is > > > very unlikely to ever be supported again. you basically will be stuck > on > > > train with no upgrade > > > path. > > > > > > > Hrishikesh > > > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney > wrote: > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > > > Hi, > > > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > > > the short answer is no > > > > > technially upstream has never supported it because it was a big > tent > > > > > projec that was > > > > > never an offical deliverable of the netwroking team. > > > > > https://github.com/openstack-archive/networking-onos has been > retired > > > > > as has https://opendev.org/openstack/networking-onos. the last > release > > > > > seams to have been from train but > > > > > even then im not sure that it was still active. > > > > > it looks like the onos projecct move the openstack install info > under > > > > > > teh > > > > > > > > obsolete paages > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > > +each+OpenStack+version> > > > > > so it does not look like the intend to support openstack anymore. > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -- Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Fri Aug 27 08:06:47 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Fri, 27 Aug 2021 10:06:47 +0200 Subject: [ci][nova] Server {uuid} failed to delete Message-ID: Hi, The gate is in a bad shape due to frequent failure of server delete tests due to placement conflicts. The bug that is tracked in [1] became more frequent after a recent placement feature (consumer_types) got landed. The nova team is aware of the situation and possible fixes are being discussed [2]. Cheers, gibi [1] http://status.openstack.org/elastic-recheck/#1836754 [2] https://review.opendev.org/q/topic:bug/1836754 From eblock at nde.ag Fri Aug 27 08:47:59 2021 From: eblock at nde.ag (Eugen Block) Date: Fri, 27 Aug 2021 08:47:59 +0000 Subject: RabbitMQ performance improvement for single-control node Message-ID: <20210827084759.Horde.DZPb-vFyM3ZJ52CXdmYHzVt@webmail.nde.ag> Hi *, I would greatly appreciate if anyone could help identifying some tweaks, if possible at all. This is a single control node environment with 19 compute nodes which are heavily used. It's still running on Pike and we won't be able to update until complete redeployment. I was able to improve the performance a lot by increasing the number of workers etc., but to me it seems the next bottleneck is rabbitmq. The rabbit process shows heavy CPU usage, almost constantly around 150% according to 'top' and I see heartbeat errors in the logs (e.g. cinder). Since there are so many config options I haven't touched them yet. Reading some of the tuning docs often refer to HA environments which is not the case here. I can paste some of the config snippets, maybe that already helps identifying anything: # nova.conf [oslo_messaging_rabbit] pool_max_size = 1600 pool_max_overflow = 1600 pool_timeout = 120 rpc_response_timeout = 120 rpc_conn_pool_size = 600 From eblock at nde.ag Fri Aug 27 08:52:44 2021 From: eblock at nde.ag (Eugen Block) Date: Fri, 27 Aug 2021 08:52:44 +0000 Subject: RabbitMQ performance improvement for single-control node In-Reply-To: <20210827084759.Horde.DZPb-vFyM3ZJ52CXdmYHzVt@webmail.nde.ag> Message-ID: <20210827085244.Horde.VqwFS-QejCLzWRl1pfJtt9R@webmail.nde.ag> Sorry, I accidentally hit "send"...adding more information. # nova.conf [oslo_messaging_notifications] driver = messagingv2 [oslo_messaging_rabbit] amqp_durable_queues = false rabbit_ha_queues = false ssl = false heartbeat_timeout_threshold = 10 # neutron.conf [oslo_messaging_rabbit] pool_max_size = 5000 pool_max_overflow = 2000 pool_timeout = 60 These are the basics in the openstack services, I don't have access to the rabbit.conf right now but I can add more information as soon as I regain access to that machine. If there's anything else I can provide to improve the user experience at least a bit please let me know. It would help a lot! Regards, Eugen Zitat von Eugen Block : > Hi *, > > I would greatly appreciate if anyone could help identifying some > tweaks, if possible at all. > > This is a single control node environment with 19 compute nodes > which are heavily used. It's still running on Pike and we won't be > able to update until complete redeployment. > I was able to improve the performance a lot by increasing the number > of workers etc., but to me it seems the next bottleneck is rabbitmq. > The rabbit process shows heavy CPU usage, almost constantly around > 150% according to 'top' and I see heartbeat errors in the logs (e.g. > cinder). Since there are so many config options I haven't touched > them yet. Reading some of the tuning docs often refer to HA > environments which is not the case here. > > I can paste some of the config snippets, maybe that already helps > identifying anything: > > # nova.conf > > [oslo_messaging_rabbit] > pool_max_size = 1600 > pool_max_overflow = 1600 > pool_timeout = 120 > rpc_response_timeout = 120 > rpc_conn_pool_size = 600 From balazs.gibizer at est.tech Fri Aug 27 09:31:25 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Fri, 27 Aug 2021 11:31:25 +0200 Subject: [ci][nova] Server {uuid} failed to delete In-Reply-To: References: Message-ID: On Fri, Aug 27, 2021 at 10:06, Balazs Gibizer wrote: > Hi, > > The gate is in a bad shape due to frequent failure of server delete > tests due to placement conflicts. The bug that is tracked in [1] > became more frequent after a recent placement feature > (consumer_types) got landed. The nova team is aware of the situation > and possible fixes are being discussed [2]. The patch [1] that supposed to fix the issue is approved and going through the gate. [1] https://review.opendev.org/c/openstack/nova/+/688802 > > Cheers, > gibi > > > [1] http://status.openstack.org/elastic-recheck/#1836754 > [2] https://review.opendev.org/q/topic:bug/1836754 > > > > From tonykarera at gmail.com Fri Aug 27 05:35:19 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 27 Aug 2021 07:35:19 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Dear Ammad, Below is the output of podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 319fbebc2f50 docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 /usr/bin/start-he... 23 hours ago Up 23 hours ago heat-container-agent [root at k8s-cluster-2-4faiphvzsmzu-master-0 core]# Regards Tony Karera On Thu, Aug 26, 2021 at 9:54 AM Ammad Syed wrote: > The output in > logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd > is incomplete. > > There should be the installation and configuration of many other things > that are missing. Also it looks that hyperkube is not installed. > > Can you check the response of "podman ps" command on master nodes. > > Ammad > > On Thu, Aug 26, 2021 at 11:30 AM Karera Tony wrote: > >> Here is the beginning of the Log >> >> Starting to run kube-apiserver-to-kubelet-role >> + echo 'Waiting for Kubernetes API...' >> Waiting for Kubernetes API... >> ++ kubectl get --raw=/healthz >> The connection to the server localhost:8080 was refused - did you specify >> the right host or port? >> + '[' ok = '' ']' >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar >> wrote: >> >>> I assume these are from the master nodes? Can you share the logs shortly >>> after creation rather than when it times out? I think there is some missing >>> logs from the top. >>> >>> Sent from my iPhone >>> >>> On 26 Aug 2021, at 06:14, Karera Tony wrote: >>> >>>  >>> Hello Guys, >>> >>> Attached are the two logs from the >>> /var/log/heat-config/heat-config-script directory >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony >>> wrote: >>> >>>> Dear Sir, >>>> >>>> You are right. >>>> >>>> I am getting this error >>>> >>>> kubectl get --raw=/healthz >>>> The connection to the server localhost:8080 was refused - did you >>>> specify the right host or port? >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >>>> wrote: >>>> >>>>> I’d check the logs under /var/log/heat-config. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>>> >>>>>  >>>>> DeaR Ammad, >>>>> >>>>> I was able to make the communication work and the Worker nodes were >>>>> created as well but the cluster failed. >>>>> >>>>> I logged in to the master node and there was no error but below are >>>>> the error when I run systemctl status heat-container-agent on the worker >>>>> noed. >>>>> >>>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>>>> wrote: >>>>> >>>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>>>> reachable from master and worker nodes. >>>>>> >>>>>> You can use below guide for the reference as well. >>>>>> >>>>>> >>>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>>> >>>>>> Ammad >>>>>> >>>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>>>> wrote: >>>>>> >>>>>>> Hello Ammad, >>>>>>> >>>>>>> I have deployed using the given image but I think there is an issue >>>>>>> with keystone as per the screen shot below when I checked the master node's >>>>>>> heat-container-agent status >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Ammad, >>>>>>>> >>>>>>>> I actually first used that one and it was also getting stuck. >>>>>>>> >>>>>>>> I will try this one again and update you with the Logs though. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>>>>> wrote: >>>>>>>> >>>>>>>>> It seems from the logs that you are using fedora atomic. Can you >>>>>>>>> try with FCOS 32 image. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>>> >>>>>>>>> Ammad >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello Sir, >>>>>>>>>> >>>>>>>>>> Attached is the Log file >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Tony Karera >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Karera, >>>>>>>>>>> >>>>>>>>>>> Can you share us the full log file. >>>>>>>>>>> >>>>>>>>>>> Ammad >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Guys, >>>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>>>> keeps appearing. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Tony Karera >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>>>> status. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Ammad >>>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> There is no directory or log relevant to heat in the >>>>>>>>>>>>> /var/log directory >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Regards >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Login to master node and check the logs of heat agent in >>>>>>>>>>>>> var log. There must be something the cluster is stucking somewhere in >>>>>>>>>>>>> creating. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Ammad >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain >>>>>>>>>>>>> point. The master node was created but the cluster remained in Creation in >>>>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>>> >>>> default-master >>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Regards >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> You can try by creating your private vxlan network prior >>>>>>>>>>>>> to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>>>> network. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I >>>>>>>>>>>>> deploy it, It creates a fixed network using vlan which I am not using for >>>>>>>>>>>>> internal networks. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the >>>>>>>>>>>>> cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>>>>> command look like? >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> -- >>>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> -- >>>>>>>>>>>>> >>> Regards, >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>>> > >>>>>>>>>>>>> > -- >>>>>>>>>>>>> > Regards, >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Syed Ammad Ali >>>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> Syed Ammad Ali >>>>>> >>>>> >>> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >>> >>> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> >>> >>> > > -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Fri Aug 27 07:15:29 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Fri, 27 Aug 2021 12:15:29 +0500 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Your hyperkube services are not started. You need to check hyperkube services. Ammad On Fri, Aug 27, 2021 at 10:35 AM Karera Tony wrote: > Dear Ammad, > > Below is the output of podman ps > > CONTAINER ID IMAGE > COMMAND CREATED STATUS PORTS NAMES > 319fbebc2f50 > docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 > /usr/bin/start-he... 23 hours ago Up 23 hours ago > heat-container-agent > [root at k8s-cluster-2-4faiphvzsmzu-master-0 core]# > > > Regards > > Tony Karera > > > > > On Thu, Aug 26, 2021 at 9:54 AM Ammad Syed wrote: > >> The output in >> logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd >> is incomplete. >> >> There should be the installation and configuration of many other things >> that are missing. Also it looks that hyperkube is not installed. >> >> Can you check the response of "podman ps" command on master nodes. >> >> Ammad >> >> On Thu, Aug 26, 2021 at 11:30 AM Karera Tony >> wrote: >> >>> Here is the beginning of the Log >>> >>> Starting to run kube-apiserver-to-kubelet-role >>> + echo 'Waiting for Kubernetes API...' >>> Waiting for Kubernetes API... >>> ++ kubectl get --raw=/healthz >>> The connection to the server localhost:8080 was refused - did you >>> specify the right host or port? >>> + '[' ok = '' ']' >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar >>> wrote: >>> >>>> I assume these are from the master nodes? Can you share the logs >>>> shortly after creation rather than when it times out? I think there is some >>>> missing logs from the top. >>>> >>>> Sent from my iPhone >>>> >>>> On 26 Aug 2021, at 06:14, Karera Tony wrote: >>>> >>>>  >>>> Hello Guys, >>>> >>>> Attached are the two logs from the >>>> /var/log/heat-config/heat-config-script directory >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony >>>> wrote: >>>> >>>>> Dear Sir, >>>>> >>>>> You are right. >>>>> >>>>> I am getting this error >>>>> >>>>> kubectl get --raw=/healthz >>>>> The connection to the server localhost:8080 was refused - did you >>>>> specify the right host or port? >>>>> >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >>>>> wrote: >>>>> >>>>>> I’d check the logs under /var/log/heat-config. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>>>> >>>>>>  >>>>>> DeaR Ammad, >>>>>> >>>>>> I was able to make the communication work and the Worker nodes were >>>>>> created as well but the cluster failed. >>>>>> >>>>>> I logged in to the master node and there was no error but below are >>>>>> the error when I run systemctl status heat-container-agent on the worker >>>>>> noed. >>>>>> >>>>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>>>>> wrote: >>>>>> >>>>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>>>>> reachable from master and worker nodes. >>>>>>> >>>>>>> You can use below guide for the reference as well. >>>>>>> >>>>>>> >>>>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>>>> >>>>>>> Ammad >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Ammad, >>>>>>>> >>>>>>>> I have deployed using the given image but I think there is an issue >>>>>>>> with keystone as per the screen shot below when I checked the master node's >>>>>>>> heat-container-agent status >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello Ammad, >>>>>>>>> >>>>>>>>> I actually first used that one and it was also getting stuck. >>>>>>>>> >>>>>>>>> I will try this one again and update you with the Logs though. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Tony Karera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> It seems from the logs that you are using fedora atomic. Can you >>>>>>>>>> try with FCOS 32 image. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>>>> >>>>>>>>>> Ammad >>>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony < >>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello Sir, >>>>>>>>>>> >>>>>>>>>>> Attached is the Log file >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Tony Karera >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed < >>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Karera, >>>>>>>>>>>> >>>>>>>>>>>> Can you share us the full log file. >>>>>>>>>>>> >>>>>>>>>>>> Ammad >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello Guys, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>>>>> keeps appearing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Karera >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>>>>> status. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Ammad >>>>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> There is no directory or log relevant to heat in the >>>>>>>>>>>>>> /var/log directory >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Regards >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Login to master node and check the logs of heat agent in >>>>>>>>>>>>>> var log. There must be something the cluster is stucking somewhere in >>>>>>>>>>>>>> creating. >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Ammad >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain >>>>>>>>>>>>>> point. The master node was created but the cluster remained in Creation in >>>>>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>>>> >>>> default-master >>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Regards >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> You can try by creating your private vxlan network >>>>>>>>>>>>>> prior to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>>>>> network. >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I >>>>>>>>>>>>>> deploy it, It creates a fixed network using vlan which I am not using for >>>>>>>>>>>>>> internal networks. >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the >>>>>>>>>>>>>> cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>>>>>> command look like? >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> -- >>>>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> -- >>>>>>>>>>>>>> >>> Regards, >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > -- >>>>>>>>>>>>>> > Regards, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Syed Ammad Ali >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Syed Ammad Ali >>>>>>> >>>>>> >>>> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >>>> >>>> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> >>>> >>>> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Fri Aug 27 12:08:36 2021 From: smooney at redhat.com (Sean Mooney) Date: Fri, 27 Aug 2021 13:08:36 +0100 Subject: Support for ONOS In-Reply-To: References: <6274919.X2OcgljGYc@p1> Message-ID: On Fri, 2021-08-27 at 13:03 +0530, Hrishikesh Karanjikar wrote: > Hi Slawek, > > Thanks for your reply. > Can you guide Which SDN controller is best and supported in Netron via ML2 > plugin/driver. in general the design of openstack/neutron is such that it owns the ovs bridges and flow rules and you as a openstack operator shoudl not need to manage anything. neutron itself is an sdn contoler that allows self service network configureation vai its rest api and an abstraction layer between the end user and underlying implemantion. it can delegate the swich configuration to external sdn contoler but even in that case you are not intned to modify flows on the integration bridge via the sdn contoler manually. the sdn contoler can be used to manage your top of rack swithc and other infrasturue not managed by neutron but there is ment to be a seperation of concerns. all networking on comptue nodes shoudl be manageged via the neutron api and only your datacenter infrastucrue should be manageve by you via the sdn contoelr. > > Thanks, > Hrishikesh > > On Fri, Aug 27, 2021 at 12:18 PM Slawek Kaplonski > wrote: > > > Hi, > > > > On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar wrote: > > > Hi Sean, > > > > > > I am new to this domain. > > > My use case is simple, > > > > > > I have a node that runs OvS and I want to manage the flows remotely using > > > an SDN controller. > > > Initially I tried with ODL but it does not have a Web UI like ONOS has. > > > So I was using ONOS. > > > I am not sure if Neutron would do the same. If it is possible then I will > > > not need any other SDN controller. > > > > Neutron is generally providing connectivity for Your VMs/routers/etc and > > it > > may use different backend. If You will use e.g. ML2 plugin with OVN > > backend, > > Neutron will configure OVN and OVN will then configure flows in OVS on the > > nodes > > to achieve that. > > But if You are looking for a tool which will allow You to see OpenFlow > > rules > > on each node, and manipulate them with some GUI, then Neutron is not for > > You. > > It don't have such functionality. > > > > > > > > I am not doing any deployment yet. > > > > > > Thanks, > > > Hrishikesh > > > > > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney wrote: > > > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > > > Hi Sean, > > > > > > > > > > Thanks for your reply. > > > > > I was expecting the same answer as I also read the github link you > > sent. > > > > > I may need to try older versions of openstack in that case. > > > > > > > > do you specificaly need onos for some reason. > > > > > > > > if not i would not suggest building a production deployment with > > something > > > > that realiticlly is > > > > very unlikely to ever be supported again. you basically will be stuck > > on > > > > train with no upgrade > > > > path. > > > > > > > > > Hrishikesh > > > > > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney > > wrote: > > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > > > > > the short answer is no > > > > > > technially upstream has never supported it because it was a big > > tent > > > > > > projec that was > > > > > > never an offical deliverable of the netwroking team. > > > > > > https://github.com/openstack-archive/networking-onos has been > > retired > > > > > > as has https://opendev.org/openstack/networking-onos. the last > > release > > > > > > seams to have been from train but > > > > > > even then im not sure that it was still active. > > > > > > it looks like the onos projecct move the openstack install info > > under > > > > > > > > teh > > > > > > > > > > obsolete paages > > > > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > > > +each+OpenStack+version> > > > > > > so it does not look like the intend to support openstack anymore. > > > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > From ricolin at ricolky.com Fri Aug 27 12:16:35 2021 From: ricolin at ricolky.com (Rico Lin) Date: Fri, 27 Aug 2021 20:16:35 +0800 Subject: [tc][all]Please help to identify common pain points & video meeting scheduled next week Message-ID: Dear all First, I thank Kendall and everyone who help with the Pain point elimination etherpad [1]. Two paths we plan to work on or would like to see how we can push it forward: 1. To identify common pain points from OpenStack. And see if we can target them in the following cycles. 2. To see if we can have a community-wide goal to encourage project teams to pick up their own pain point in the following cycles. *This ML is focused on the first path; To identify common pain points.* So I would like to encourage all to help to identify common pain points from it and also help put your feedbacks on the etherpad [1]. To identify common pain points, you can help to leave comments to pain points that you feel it is not an issue for a single project team but for a larger scope. We kind of recognized rabbitmq (or said RPC backend) might be one of the common pain points from that etherpad. And we wish to learn more from all of you. And we need operators' feedback mostly. Also, *we plan to put `identify common pain points` on schedule for the TC meeting next week (which is a video meeting on google meet). If you're interested, please help with etherpad, and join the TC meeting [2] next week.* [1] https://etherpad.opendev.org/p/pain-point-elimination [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer at EasyStack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrishikesh.karanjikar at gmail.com Fri Aug 27 13:39:28 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Fri, 27 Aug 2021 19:09:28 +0530 Subject: Support for ONOS In-Reply-To: References: <6274919.X2OcgljGYc@p1> Message-ID: Hi Sean, Thanks a lot for the clarification. I am wondering how smart nics attached to a compute node (which runs ovs-dpdk) can be configured using sdn controllers so that the ovs/tunneling/ipsec functionality on the compute node is offloaded to smartnic and compute node cpu is free to do other stuffs? Thanks, Hrishikesh On Fri, Aug 27, 2021 at 5:38 PM Sean Mooney wrote: > On Fri, 2021-08-27 at 13:03 +0530, Hrishikesh Karanjikar wrote: > > Hi Slawek, > > > > Thanks for your reply. > > Can you guide Which SDN controller is best and supported in Netron via > ML2 > > plugin/driver. > > in general the design of openstack/neutron is such that it owns the ovs > bridges and > flow rules and you as a openstack operator shoudl not need to manage > anything. > > neutron itself is an sdn contoler that allows self service network > configureation vai > its rest api and an abstraction layer between the end user and underlying > implemantion. > > it can delegate the swich configuration to external sdn contoler but even > in that case > you are not intned to modify flows on the integration bridge via the sdn > contoler manually. > > the sdn contoler can be used to manage your top of rack swithc and other > infrasturue not managed > by neutron but there is ment to be a seperation of concerns. all > networking on comptue nodes shoudl be > manageged via the neutron api and only your datacenter infrastucrue should > be manageve by you via the > sdn contoelr. > > > > > > Thanks, > > Hrishikesh > > > > On Fri, Aug 27, 2021 at 12:18 PM Slawek Kaplonski > > wrote: > > > > > Hi, > > > > > > On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar wrote: > > > > Hi Sean, > > > > > > > > I am new to this domain. > > > > My use case is simple, > > > > > > > > I have a node that runs OvS and I want to manage the flows remotely > using > > > > an SDN controller. > > > > Initially I tried with ODL but it does not have a Web UI like ONOS > has. > > > > So I was using ONOS. > > > > I am not sure if Neutron would do the same. If it is possible then I > will > > > > not need any other SDN controller. > > > > > > Neutron is generally providing connectivity for Your VMs/routers/etc > and > > > it > > > may use different backend. If You will use e.g. ML2 plugin with OVN > > > backend, > > > Neutron will configure OVN and OVN will then configure flows in OVS on > the > > > nodes > > > to achieve that. > > > But if You are looking for a tool which will allow You to see OpenFlow > > > rules > > > on each node, and manipulate them with some GUI, then Neutron is not > for > > > You. > > > It don't have such functionality. > > > > > > > > > > > I am not doing any deployment yet. > > > > > > > > Thanks, > > > > Hrishikesh > > > > > > > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney > wrote: > > > > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > > > > Hi Sean, > > > > > > > > > > > > Thanks for your reply. > > > > > > I was expecting the same answer as I also read the github link > you > > > sent. > > > > > > I may need to try older versions of openstack in that case. > > > > > > > > > > do you specificaly need onos for some reason. > > > > > > > > > > if not i would not suggest building a production deployment with > > > something > > > > > that realiticlly is > > > > > very unlikely to ever be supported again. you basically will be > stuck > > > on > > > > > train with no upgrade > > > > > path. > > > > > > > > > > > Hrishikesh > > > > > > > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney > > > wrote: > > > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > > > > > > > the short answer is no > > > > > > > technially upstream has never supported it because it was a big > > > tent > > > > > > > projec that was > > > > > > > never an offical deliverable of the netwroking team. > > > > > > > https://github.com/openstack-archive/networking-onos has been > > > retired > > > > > > > as has https://opendev.org/openstack/networking-onos. the last > > > release > > > > > > > seams to have been from train but > > > > > > > even then im not sure that it was still active. > > > > > > > it looks like the onos projecct move the openstack install info > > > under > > > > > > > > > > teh > > > > > > > > > > > > obsolete paages > > > > > > > > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > > > > +each+OpenStack+version> > > > > > > > so it does not look like the intend to support openstack > anymore. > > > > > > > > > -- > > > Slawek Kaplonski > > > Principal Software Engineer > > > Red Hat > > > > > > > > > -- Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Fri Aug 27 14:10:39 2021 From: smooney at redhat.com (Sean Mooney) Date: Fri, 27 Aug 2021 15:10:39 +0100 Subject: Support for ONOS In-Reply-To: References: <6274919.X2OcgljGYc@p1> Message-ID: <31c8ca01da68b9ef041897b01717ec4a0c5435ac.camel@redhat.com> On Fri, 2021-08-27 at 19:09 +0530, Hrishikesh Karanjikar wrote: > Hi Sean, > > Thanks a lot for the clarification. > I am wondering how smart nics attached to a compute node (which runs > ovs-dpdk) can be configured using sdn controllers so that the > ovs/tunneling/ipsec functionality on the compute node is offloaded to > smartnic and compute node cpu is free to do other stuffs? i responed privatly too but what you are discribing is hardware offloaded ovs https://docs.openstack.org/neutron/latest/admin/config-ovs-offload.html which is supported by ml2/ovs and ml2/ovn although with most testign done with ml2/ovs in general this feature is not compatible with sdn contolers today although as i noted in my other respocne contrail has limited support for hardwar offload with there vrouter solution but i generally do not recommend that solution since it has miniumal testing upstream. there is some other work to move ovs entirely to run on the smart nics where those smatnics have embded arm cores. that work is very much not ready for production and still under design there are 3 competting approches to taht on via ironic one via cybrog and one in nova. they all work slightly differnetly and serve slightly differnt usecase and hardware. if you want somethin you can use today or even in the next 12 months you want hardware offload ovs with ml2/ovs or possibel ml2/ovn although ovn support for hardware offload is much newer and less well tested although long term that is likely where more of the investment will go. > > Thanks, > Hrishikesh > > On Fri, Aug 27, 2021 at 5:38 PM Sean Mooney wrote: > > > On Fri, 2021-08-27 at 13:03 +0530, Hrishikesh Karanjikar wrote: > > > Hi Slawek, > > > > > > Thanks for your reply. > > > Can you guide Which SDN controller is best and supported in Netron via > > ML2 > > > plugin/driver. > > > > in general the design of openstack/neutron is such that it owns the ovs > > bridges and > > flow rules and you as a openstack operator shoudl not need to manage > > anything. > > > > neutron itself is an sdn contoler that allows self service network > > configureation vai > > its rest api and an abstraction layer between the end user and underlying > > implemantion. > > > > it can delegate the swich configuration to external sdn contoler but even > > in that case > > you are not intned to modify flows on the integration bridge via the sdn > > contoler manually. > > > > the sdn contoler can be used to manage your top of rack swithc and other > > infrasturue not managed > > by neutron but there is ment to be a seperation of concerns. all > > networking on comptue nodes shoudl be > > manageged via the neutron api and only your datacenter infrastucrue should > > be manageve by you via the > > sdn contoelr. > > > > > > > > > > Thanks, > > > Hrishikesh > > > > > > On Fri, Aug 27, 2021 at 12:18 PM Slawek Kaplonski > > > wrote: > > > > > > > Hi, > > > > > > > > On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar wrote: > > > > > Hi Sean, > > > > > > > > > > I am new to this domain. > > > > > My use case is simple, > > > > > > > > > > I have a node that runs OvS and I want to manage the flows remotely > > using > > > > > an SDN controller. > > > > > Initially I tried with ODL but it does not have a Web UI like ONOS > > has. > > > > > So I was using ONOS. > > > > > I am not sure if Neutron would do the same. If it is possible then I > > will > > > > > not need any other SDN controller. > > > > > > > > Neutron is generally providing connectivity for Your VMs/routers/etc > > and > > > > it > > > > may use different backend. If You will use e.g. ML2 plugin with OVN > > > > backend, > > > > Neutron will configure OVN and OVN will then configure flows in OVS on > > the > > > > nodes > > > > to achieve that. > > > > But if You are looking for a tool which will allow You to see OpenFlow > > > > rules > > > > on each node, and manipulate them with some GUI, then Neutron is not > > for > > > > You. > > > > It don't have such functionality. > > > > > > > > > > > > > > I am not doing any deployment yet. > > > > > > > > > > Thanks, > > > > > Hrishikesh > > > > > > > > > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney > > wrote: > > > > > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > > > > > Hi Sean, > > > > > > > > > > > > > > Thanks for your reply. > > > > > > > I was expecting the same answer as I also read the github link > > you > > > > sent. > > > > > > > I may need to try older versions of openstack in that case. > > > > > > > > > > > > do you specificaly need onos for some reason. > > > > > > > > > > > > if not i would not suggest building a production deployment with > > > > something > > > > > > that realiticlly is > > > > > > very unlikely to ever be supported again. you basically will be > > stuck > > > > on > > > > > > train with no upgrade > > > > > > path. > > > > > > > > > > > > > Hrishikesh > > > > > > > > > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney > > > > wrote: > > > > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > > > > > > > > > the short answer is no > > > > > > > > technially upstream has never supported it because it was a big > > > > tent > > > > > > > > projec that was > > > > > > > > never an offical deliverable of the netwroking team. > > > > > > > > https://github.com/openstack-archive/networking-onos has been > > > > retired > > > > > > > > as has https://opendev.org/openstack/networking-onos. the last > > > > release > > > > > > > > seams to have been from train but > > > > > > > > even then im not sure that it was still active. > > > > > > > > it looks like the onos projecct move the openstack install info > > > > under > > > > > > > > > > > > teh > > > > > > > > > > > > > > obsolete paages > > > > > > > > > > > > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > > > > > +each+OpenStack+version> > > > > > > > > so it does not look like the intend to support openstack > > anymore. > > > > > > > > > > > > -- > > > > Slawek Kaplonski > > > > Principal Software Engineer > > > > Red Hat > > > > > > > > > > > > > > > > From gmann at ghanshyammann.com Fri Aug 27 14:37:55 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Aug 2021 09:37:55 -0500 Subject: [tempest] Tempest gate is blocked by tempest plugins sanity check job Message-ID: <17b880bbc14.1224a65a4299098.2653344898237215936@ghanshyammann.com> Hello Everyone, Tempest gate is blocked by tempest plugin sanity job which is failing 100% for x/vmware-nsx-tempest-plugin issue. - https://zuul.opendev.org/t/openstack/builds?job_name=tempest-tox-plugin-sanity-check Please avoid recheck until the below patch to blacklist failing plugin is merged - https://review.opendev.org/c/openstack/tempest/+/806411 -gmann From akanevsk at redhat.com Fri Aug 27 14:49:15 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 27 Aug 2021 10:49:15 -0400 Subject: [Nova][interop] Message-ID: Sean and Nova team, Interop WG would like 20-30 minutes on Yaga PTG agenda to discuss latest interop guidelines for Nova. If you can point us to etherpad then we can add it to agenda. 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 skaplons at redhat.com Fri Aug 27 14:52:33 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 27 Aug 2021 16:52:33 +0200 Subject: [neutron] Welcome Lajos Katona in the drivers team Message-ID: <5179442.FjUNWHvIh7@p1> Hi, Since very long time Lajos is one of the most active Neutron contributors and core reviewers. Now he will also be Neutron PTL. Giving all of that I asked on today's drivers-meeting about nominating Lajos Katona to the neutron-drivers team and we all agreed there that Lajos deserves to be part of that team and will be great addition there [1]. So I just added him to the neutron-drivers. Thx for all You work and welcome in the team Lajos! [1] https://meetings.opendev.org/meetings/neutron_drivers/2021/ neutron_drivers.2021-08-27-14.00.log.html#l-18 -- 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 gmann at ghanshyammann.com Fri Aug 27 15:08:23 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Aug 2021 10:08:23 -0500 Subject: [Nova][interop] In-Reply-To: References: Message-ID: <17b8827a008.1105017ee301036.2872782249905206264@ghanshyammann.com> HI Arkady, Please add it in https://etherpad.opendev.org/p/nova-yoga-ptg also it will be good to add detail about specific thing to discuss as nova API changes are with microversion so they do not actually effect current guidelines until interop start doing the microversion capability. -gmann ---- On Fri, 27 Aug 2021 09:49:15 -0500 Arkady Kanevsky wrote ---- > Sean and Nova team,Interop WG would like 20-30 minutes on Yaga PTG agenda to discuss latest interop guidelines for Nova.If you can point us to etherpad then we can add it to agenda.Thanks,Arkady > > -- > Arkady Kanevsky, Ph.D.Phone: 972 707-6456Corporate Phone: 919 729-5744 ext. 8176456 > From akanevsk at redhat.com Fri Aug 27 15:14:24 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 27 Aug 2021 11:14:24 -0400 Subject: [Nova][interop] In-Reply-To: <17b8827a008.1105017ee301036.2872782249905206264@ghanshyammann.com> References: <17b8827a008.1105017ee301036.2872782249905206264@ghanshyammann.com> Message-ID: Thanks Ghanshyam. I will add time slot now, and detail of the meeting later when we have a draft of next interop guidelines. Thanks,Arkady On Fri, Aug 27, 2021 at 11:08 AM Ghanshyam Mann wrote: > HI Arkady, > > Please add it in https://etherpad.opendev.org/p/nova-yoga-ptg > > also it will be good to add detail about specific thing to discuss as nova > API changes are with microversion so they do not actually > effect current guidelines until interop start doing the microversion > capability. > > -gmann > > > ---- On Fri, 27 Aug 2021 09:49:15 -0500 Arkady Kanevsky < > akanevsk at redhat.com> wrote ---- > > Sean and Nova team,Interop WG would like 20-30 minutes on Yaga PTG > agenda to discuss latest interop guidelines for Nova.If you can point us to > etherpad then we can add it to agenda.Thanks,Arkady > > > > -- > > 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 27 15:42:31 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Fri, 27 Aug 2021 15:42:31 +0000 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> <0670B960225633449A24709C291A525251C86EC8@COM03.performair.local> Message-ID: <0670B960225633449A24709C291A525251C8972E@COM03.performair.local> Kris; Utilizing the VirtIO drivers allows the use of para-virtualized hardware, instead of fully virtualized hardware. This would improve the performance of disk related operations within the VM. If you inject the drivers, you can also drop the --property hw_disk_bus=ide from your images. 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: Wednesday, August 25, 2021 11:05 PM To: openstack-discuss at lists.openstack.org Subject: Re: Windows2012 VM image importing and Instance Launch Failure A bit of confusion reading this document for Windows VMs to OpenStack.  It's quite old. But I need to clarify with list members. https://superuser.openstack.org/articles/how-to-migrate-from-vmware-and-hyper-v-to-openstack/ Is this virtIO driver injection methods still relevant for migrating Windows VMs  from Other hypervisors ( in my case HyperV) to OpenStack (  qemu KVM, USSURI version ).  On Wed, Aug 25, 2021 at 9:12 PM wrote: Kris;   This shouldn’t be all that much more difficult than Linux, nor that much harder than a single-disk Windows VM. Thanks: I am going to follow as you guided here.    But I came across the above link a few days back while referring to online documents, Is this  VirtIO injection steps necessary nowadays( as the  article on the link refers to year 2015 or so. Kindly enlighten me about the relevance of VirtIO injection now also if applicable. But for Single disk WIndows VM importing to my OpenStack,  I did not do the VirtIO injection steps:) .  Am I doing wrong here ?   I am able to get the Single disk Windows VM imported to OpenStack and  the instance running and able to login with  administrator credentials.    I would start by disabling the SQL service, as the OpenStack instance will boot once before you can add the data disks (at least it does for me when using Horizon).   Export the disks, convert then, and import them, all as you normally would.  Create the instance, as you normally would.  The instance will start; shut it back down.  Attach the additional volumes, and start the instance back up.   It would be nice to have an option to not start the instance after creation.   You could also investigate the “openstack server create” command; it has a --volume argument that you may be able to pass more than once, though I suspect not.   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: Tuesday, August 24, 2021 11:19 PM To: openstack-discuss at lists.openstack.org Subject: Re: Windows2012 VM image importing and Instance Launch Failure   Thank you all.    I am able to get the Single disk Windows VM  exported from HyperV  and  imported to OpenStack(Ussuri, Glance and Qemu KVM )  Instance launched and its showing the status running  in the PowerState Tab of Horizon dashboard.    (need to check with the administrator user to login and confirm the VM is working as expected . )     My second phase :    I need to perform  importing   multiple disk   Windows VM to   my OpenStack setup  .   ( For single disk  Windows vhdx file, I 've converted it to qcow2 file and imported to OpenStack as the steps  I posted in my  previous emails. )   Now how can I   import Multiple disk Windows VM  to  OpenStack.       First Step  is  to convert the  vhdx files exported from HyperV to  qcow2  files.    After this step ,   what steps need to be performed   to bring a multi disk Windows VM to  OpeStack ?   For Eg:  I have a Windows VM       1. with  Application server  1TB single disk image exported from hyperV.  This I can import to  my OpenStack setup with the steps I followed in my earlier emails as it is a single disk image.     2.  A Database server for the above application with   700 GB  in multiple disks.  ( 100 and 600 GB disks images exported from HyperV  and in vhdx format  for DB server)   How to bring this server imported to   my  OpeStack setup (ussuri, glance and QEMU KVM).   As this is from Windows  HyperV  I  am new to multidisk environment from Windows. ( for Linux VMs exported from oVirt(RHVM) I am able to import multidisk  VMs to OpenStack as they are in LVM and I have to mount it with VG name and adding entries in /etc/fstab file )   But in Windows multi disks how to perform this ?  what steps I have to perform to import this to OpenStack.    Any hints or suggestions most welcome..   Kris     On Tue, Aug 24, 2021 at 1:40 PM Eugen Block wrote: Of course you need a running nova-conductor, how did you launch VMs before? Zitat von KK CHN : > 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. >> From hrishikesh.karanjikar at gmail.com Fri Aug 27 15:45:43 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Fri, 27 Aug 2021 21:15:43 +0530 Subject: Support for ONOS In-Reply-To: <31c8ca01da68b9ef041897b01717ec4a0c5435ac.camel@redhat.com> References: <6274919.X2OcgljGYc@p1> <31c8ca01da68b9ef041897b01717ec4a0c5435ac.camel@redhat.com> Message-ID: Hi Sean, In my last email I forgot to add the openstack discussion email so I sent it again. I am really great ful for the insight you have provided. I will check the links and ml2/ovs ml2/ovn support mentioned by you. Thanks, Hrishikesh On Fri, Aug 27, 2021, 7:41 PM Sean Mooney wrote: > On Fri, 2021-08-27 at 19:09 +0530, Hrishikesh Karanjikar wrote: > > Hi Sean, > > > > Thanks a lot for the clarification. > > I am wondering how smart nics attached to a compute node (which runs > > ovs-dpdk) can be configured using sdn controllers so that the > > ovs/tunneling/ipsec functionality on the compute node is offloaded to > > smartnic and compute node cpu is free to do other stuffs? > > i responed privatly too but what you are discribing is hardware offloaded > ovs > https://docs.openstack.org/neutron/latest/admin/config-ovs-offload.html > which is supported by ml2/ovs and ml2/ovn although with most testign done > with ml2/ovs > > in general this feature is not compatible with sdn contolers today > although as i noted > in my other respocne contrail has limited support for hardwar offload with > there vrouter solution > but i generally do not recommend that solution since it has miniumal > testing upstream. > > there is some other work to move ovs entirely to run on the smart nics > where those smatnics have > embded arm cores. that work is very much not ready for production and > still under design > there are 3 competting approches to taht on via ironic one via cybrog and > one in nova. > they all work slightly differnetly and serve slightly differnt usecase and > hardware. > > if you want somethin you can use today or even in the next 12 months you > want hardware offload > ovs with ml2/ovs or possibel ml2/ovn although ovn support for hardware > offload is much newer and > less well tested although long term that is likely where more of the > investment will go. > > > > > Thanks, > > Hrishikesh > > > > On Fri, Aug 27, 2021 at 5:38 PM Sean Mooney wrote: > > > > > On Fri, 2021-08-27 at 13:03 +0530, Hrishikesh Karanjikar wrote: > > > > Hi Slawek, > > > > > > > > Thanks for your reply. > > > > Can you guide Which SDN controller is best and supported in Netron > via > > > ML2 > > > > plugin/driver. > > > > > > in general the design of openstack/neutron is such that it owns the ovs > > > bridges and > > > flow rules and you as a openstack operator shoudl not need to manage > > > anything. > > > > > > neutron itself is an sdn contoler that allows self service network > > > configureation vai > > > its rest api and an abstraction layer between the end user and > underlying > > > implemantion. > > > > > > it can delegate the swich configuration to external sdn contoler but > even > > > in that case > > > you are not intned to modify flows on the integration bridge via the > sdn > > > contoler manually. > > > > > > the sdn contoler can be used to manage your top of rack swithc and > other > > > infrasturue not managed > > > by neutron but there is ment to be a seperation of concerns. all > > > networking on comptue nodes shoudl be > > > manageged via the neutron api and only your datacenter infrastucrue > should > > > be manageve by you via the > > > sdn contoelr. > > > > > > > > > > > > > > Thanks, > > > > Hrishikesh > > > > > > > > On Fri, Aug 27, 2021 at 12:18 PM Slawek Kaplonski < > skaplons at redhat.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > On piątek, 27 sierpnia 2021 07:18:10 CEST Hrishikesh Karanjikar > wrote: > > > > > > Hi Sean, > > > > > > > > > > > > I am new to this domain. > > > > > > My use case is simple, > > > > > > > > > > > > I have a node that runs OvS and I want to manage the flows > remotely > > > using > > > > > > an SDN controller. > > > > > > Initially I tried with ODL but it does not have a Web UI like > ONOS > > > has. > > > > > > So I was using ONOS. > > > > > > I am not sure if Neutron would do the same. If it is possible > then I > > > will > > > > > > not need any other SDN controller. > > > > > > > > > > Neutron is generally providing connectivity for Your > VMs/routers/etc > > > and > > > > > it > > > > > may use different backend. If You will use e.g. ML2 plugin with OVN > > > > > backend, > > > > > Neutron will configure OVN and OVN will then configure flows in > OVS on > > > the > > > > > nodes > > > > > to achieve that. > > > > > But if You are looking for a tool which will allow You to see > OpenFlow > > > > > rules > > > > > on each node, and manipulate them with some GUI, then Neutron is > not > > > for > > > > > You. > > > > > It don't have such functionality. > > > > > > > > > > > > > > > > > I am not doing any deployment yet. > > > > > > > > > > > > Thanks, > > > > > > Hrishikesh > > > > > > > > > > > > On Thu, Aug 26, 2021 at 5:00 PM Sean Mooney > > > wrote: > > > > > > > On Thu, 2021-08-26 at 16:41 +0530, Hrishikesh Karanjikar wrote: > > > > > > > > Hi Sean, > > > > > > > > > > > > > > > > Thanks for your reply. > > > > > > > > I was expecting the same answer as I also read the github > link > > > you > > > > > sent. > > > > > > > > I may need to try older versions of openstack in that case. > > > > > > > > > > > > > > do you specificaly need onos for some reason. > > > > > > > > > > > > > > if not i would not suggest building a production deployment > with > > > > > something > > > > > > > that realiticlly is > > > > > > > very unlikely to ever be supported again. you basically will be > > > stuck > > > > > on > > > > > > > train with no upgrade > > > > > > > path. > > > > > > > > > > > > > > > Hrishikesh > > > > > > > > > > > > > > > > On Thu, Aug 26, 2021 at 4:27 PM Sean Mooney < > smooney at redhat.com> > > > > > wrote: > > > > > > > > > On Thu, 2021-08-26 at 15:31 +0530, Hrishikesh Karanjikar > wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Does Openstack latest release support ONOS? > > > > > > > > > > > > > > > > > > the short answer is no > > > > > > > > > technially upstream has never supported it because it was > a big > > > > > tent > > > > > > > > > projec that was > > > > > > > > > never an offical deliverable of the netwroking team. > > > > > > > > > https://github.com/openstack-archive/networking-onos has > been > > > > > retired > > > > > > > > > as has https://opendev.org/openstack/networking-onos. the > last > > > > > release > > > > > > > > > seams to have been from train but > > > > > > > > > even then im not sure that it was still active. > > > > > > > > > it looks like the onos projecct move the openstack install > info > > > > > under > > > > > > > > > > > > > > teh > > > > > > > > > > > > > > > > obsolete paages > > > > > > > > > > > > > > > > > > > > > > > https://wiki.onosproject.org/display/ONOS/networking-onos+install+guides+per > > > > > > > +each+OpenStack+version> > > > > > > > > > so it does not look like the intend to support openstack > > > anymore. > > > > > > > > > > > > > > > -- > > > > > Slawek Kaplonski > > > > > Principal Software Engineer > > > > > Red Hat > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Aug 27 16:16:11 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 27 Aug 2021 18:16:11 +0200 Subject: [release] Release countdown for week R-5, Aug 30 - Sep 03 Message-ID: Development Focus ----------------- We are getting close to the end of the Xena cycle! Next week on 02 September, 2021 is the Xena-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Yoga cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on 02 September, 2021. Only bugfix 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 02 September, 2021 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights for more details. Upcoming Deadlines & Dates -------------------------- Xena-3 milestone (feature freeze): 02 September, 2021 (R-5 week) RC1 deadline: The week of 13 September, 2021 (R-3 week) Final RC deadline: The week of 27 September, 2021 (R-1 week) Final Xena release: 06 October, 2021 -- 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 sz_cuitao at 163.com Fri Aug 27 16:39:28 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Sat, 28 Aug 2021 00:39:28 +0800 Subject: Why the mariadb container always restart ? Message-ID: <003201d79b62$1bca9300$535fb900$@163.com> Hi: The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. Ant this is the log : 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, 'tcp://10.10.10.63:4567') turning message relay requesting off 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out) at gcomm/src/pc.cpp:connect():160 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out) 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 (Connection timed out) 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection timed out 2021-08-28 0:35:03 0 [ERROR] WSREP: wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567) failed: 7 2021-08-28 0:35:03 0 [ERROR] Aborting 210828 00:35:05 mysqld_safe mysqld from pid file /var/lib/mysql/mariadb.pid ended 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/ 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' 210828 00:35:12 mysqld_safe WSREP: Recovered position 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, skipping position init 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://10.10.10.63:4567; gmcast.segment = 0; gmc 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for certification: 140403, protocol version: -1 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() 2021-08-28 0:35:12 0 [Note] WSREP: Start replication 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority set to other:0 2021-08-28 0:35:12 0 [Warning] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') multicast: , ttl: 1 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') connection established to b1ae23e3 tcp://10.10.10.62:4567 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting off 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') connection established to c296912b tcp://10.10.10.61:4567 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at tcp://10.10.10.62:4567 stable 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at tcp://10.10.10.61:4567 stable 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, prim not possible What's matter with it ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Aug 27 17:05:50 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 27 Aug 2021 19:05:50 +0200 Subject: Why the mariadb container always restart ? In-Reply-To: <003201d79b62$1bca9300$535fb900$@163.com> References: <003201d79b62$1bca9300$535fb900$@163.com> Message-ID: On Fri, Aug 27, 2021 at 6:56 PM Tommy Sway wrote: > > Hi: > > > > The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. > > > > Ant this is the log : > > > > > > 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out) > > at gcomm/src/pc.cpp:connect():160 > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection timed out > > 2021-08-28 0:35:03 0 [ERROR] WSREP: wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567) failed: 7 > > 2021-08-28 0:35:03 0 [ERROR] Aborting > > > > 210828 00:35:05 mysqld_safe mysqld from pid file /var/lib/mysql/mariadb.pid ended > > 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/ > > 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' > > 210828 00:35:12 mysqld_safe WSREP: Recovered position 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, skipping position init > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' > > 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. > > 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. > > 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://10.10.10.63:4567; gmcast.segment = 0; gmc > > 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for certification: 140403, protocol version: -1 > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() > > 2021-08-28 0:35:12 0 [Note] WSREP: Start replication > > 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. > > 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority set to other:0 > > 2021-08-28 0:35:12 0 [Warning] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) > > 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed > > 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') multicast: , ttl: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') connection established to b1ae23e3 tcp://10.10.10.62:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') connection established to c296912b tcp://10.10.10.61:4567 > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at tcp://10.10.10.62:4567 stable > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at tcp://10.10.10.61:4567 stable > > 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, prim not possible > > > > > > What’s matter with it ? > > After lights-out, you have to run ``kolla-ansible mariadb_recovery`` to safely recover the Galera cluster state. -yoctozepto From Daniel.Pereira at windriver.com Fri Aug 27 17:59:55 2021 From: Daniel.Pereira at windriver.com (Daniel de Oliveira Pereira) Date: Fri, 27 Aug 2021 14:59:55 -0300 Subject: [dev][cinder] Consultation about new cinder-backup features Message-ID: Hello everyone, We have prototyped some new features on Cinder for our clients, and we think that they are nice features and good candidates to be part of upstream Cinder, so we would like to get feedback from OpenStack community about these features and if you would be willing to accept them in upstream OpenStack. Our team implemented the following features for cinder-backup service: 1. A multi-backend backup driver, that allow OpenStack users to choose, via API/CLI/Horizon, which backup driver (Ceph or NFS, in our prototype) will be used during a backup operation to create a new volume backup. 2. An improved NFS backup driver, that allow OpenStack users to back up their volumes to private NFS servers, providing the NFS hostpath at runtime via API/CLI/Horizon, while creating the volume backup. Considering that cinder was configured to use the multi-backend backup driver, this is how it works: During a volume backup operation, the user provides a "location" parameter to indicate which backend will be used, and the backup hostpath, if applicable (for NFS driver), to create the volume backup. For instance: - Creating a backup using Ceph backend: $ openstack volume backup create --name --location ceph - Creating a backup using the improved NFS backend: $ openstack volume backup create --name --location nfs://my.nfs.server:/backups If the user chooses Ceph backend, the Ceph driver will be used to create the backup. If the user chooses the NFS backend, the improved NFS driver, previously mentioned, will be used to create the backup. The backup location, if provided, is stored on Cinder database, and can be seen fetching the backup details: $ openstack volume backup show Briefly, this is how the features were implemented: - Cinder API was updated to add an optional location parameter to "create backup" method. Horizon, and OpenStack and Cinder CLIs were updated accordingly, to handle the new parameter. - Cinder backup controller was updated to handle the backup location parameter, and a validator for the parameter was implemented using the oslo config library. - Cinder backup object model was updated to add a nullable location property, so that the backup location could be stored on cinder database. - a new backup driver base class, that extends BackupDriver and accepts a backup context object, was implemented to handle the backup configuration provided at runtime by the user. This new backup base class requires that the concrete drivers implement a method to validate the backup context (similar to BackupDriver.check_for_setup_error) - the 2 new backup drivers, previously mentioned, were implemented using these new backup base class. - in BackupManager class, the "service" attribute, that on upstream OpenStack holds the backup driver class name, was re-implemented as a factory function that accepts a backup context object and return an instance of a backup driver, according to the backup driver configured on cinder.conf file and the backup context provided at runtime by the user. - All the backup operations continue working as usual. Could you please let us know your thoughts about these features and if you would be open to adding them to upstream Cinder? If yes, we would be willing to submit the specs and work on the upstream implementation, if they are approved. Regards, Daniel Pereira From akanevsk at redhat.com Fri Aug 27 18:06:52 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 27 Aug 2021 14:06:52 -0400 Subject: [dev][cinder] Consultation about new cinder-backup features In-Reply-To: References: Message-ID: How will that work with 3rd cinder party drivers? On Fri, Aug 27, 2021 at 2:02 PM Daniel de Oliveira Pereira < Daniel.Pereira at windriver.com> wrote: > Hello everyone, > > We have prototyped some new features on Cinder for our clients, and we > think that they are nice features and good candidates to be part of > upstream Cinder, so we would like to get feedback from OpenStack > community about these features and if you would be willing to accept > them in upstream OpenStack. > > Our team implemented the following features for cinder-backup service: > > 1. A multi-backend backup driver, that allow OpenStack users to > choose, via API/CLI/Horizon, which backup driver (Ceph or NFS, in our > prototype) will be used during a backup operation to create a new volume > backup. > 2. An improved NFS backup driver, that allow OpenStack users to back > up their volumes to private NFS servers, providing the NFS hostpath at > runtime via API/CLI/Horizon, while creating the volume backup. > > Considering that cinder was configured to use the multi-backend backup > driver, this is how it works: > > During a volume backup operation, the user provides a "location" > parameter to indicate which backend will be used, and the backup > hostpath, if applicable (for NFS driver), to create the volume backup. > For instance: > > - Creating a backup using Ceph backend: > $ openstack volume backup create --name --location > ceph > > - Creating a backup using the improved NFS backend: > $ openstack volume backup create --name --location > nfs://my.nfs.server:/backups > > If the user chooses Ceph backend, the Ceph driver will be used to > create the backup. If the user chooses the NFS backend, the improved NFS > driver, previously mentioned, will be used to create the backup. > > The backup location, if provided, is stored on Cinder database, and > can be seen fetching the backup details: > $ openstack volume backup show > > Briefly, this is how the features were implemented: > > - Cinder API was updated to add an optional location parameter to > "create backup" method. Horizon, and OpenStack and Cinder CLIs were > updated accordingly, to handle the new parameter. > - Cinder backup controller was updated to handle the backup location > parameter, and a validator for the parameter was implemented using the > oslo config library. > - Cinder backup object model was updated to add a nullable location > property, so that the backup location could be stored on cinder database. > - a new backup driver base class, that extends BackupDriver and > accepts a backup context object, was implemented to handle the backup > configuration provided at runtime by the user. This new backup base > class requires that the concrete drivers implement a method to validate > the backup context (similar to BackupDriver.check_for_setup_error) > - the 2 new backup drivers, previously mentioned, were implemented > using these new backup base class. > - in BackupManager class, the "service" attribute, that on upstream > OpenStack holds the backup driver class name, was re-implemented as a > factory function that accepts a backup context object and return an > instance of a backup driver, according to the backup driver configured > on cinder.conf file and the backup context provided at runtime by the user. > - All the backup operations continue working as usual. > > Could you please let us know your thoughts about these features and if > you would be open to adding them to upstream Cinder? If yes, we would be > willing to submit the specs and work on the upstream implementation, if > they are approved. > > Regards, > Daniel Pereira > > -- 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 27 18:45:18 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Aug 2021 13:45:18 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 27th Aug, 21: Reading: 5 min Message-ID: <17b88ee394b.e250a6be309358.7199518501144182224@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 26th Thursday. * Most of the meeting discussions are summarized 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-26-15.00.log.html * We will have next week's meeting (Video call) on Sept 2nd, Thursday 15:00 UTC, feel free the topic in agenda [1] by Sept 1st. 2. What we completed this week: ========================= * "Secure RBAC" is selected as one of the community wide goal for Yoga cycle[2]. * TC discussed and agreed on having monthly (1st meeting of every month) Video meeting. First Video meeting on 2nd Sept (next week meeting I will send the joining detail next week). The rest of other weeks meeting will be on IRC. 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 ---------------------------------------------------- * TC election results are out (no election this time)[5]. * PTL election are going on, Cyborg project will have election. 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. Collecting Pain points from projects/SIGs/pop-up ----------------------------------------------------------- * We have lot of pain points from different projects as listed in etherpad[8]. * As next step, we are going to identify the common pain point which can be targeted as community-wide goal. * Join us in discussion in next week meeting and do not miss to read Rico detail email on this[9]. Project updates ------------------- * Retiring js-openstack-lib [10] * Retire puppet-monasca[11] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [12]. * Current status: "Secure RBAC" is selected for Yoga cycle[13]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[14], 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[15], 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[16]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [17] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [18] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/803783 [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/024403.html [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html [7] https://review.opendev.org/c/openstack/governance/+/804824 [8] https://etherpad.opendev.org/p/pain-point-elimination [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024487.html [9] https://review.opendev.org/c/openstack/governance/+/798540 [10] https://review.opendev.org/c/openstack/governance/+/805105 [12] https://etherpad.opendev.org/p/y-series-goals [13] https://review.opendev.org/c/openstack/governance/+/803783 [14] https://etherpad.opendev.org/p/tc-yoga-ptg [15] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [16] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [17] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [18] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann From gmann at ghanshyammann.com Fri Aug 27 19:35:35 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Aug 2021 14:35:35 -0500 Subject: [tempest] Tempest gate is blocked by tempest plugins sanity check job In-Reply-To: <17b880bbc14.1224a65a4299098.2653344898237215936@ghanshyammann.com> References: <17b880bbc14.1224a65a4299098.2653344898237215936@ghanshyammann.com> Message-ID: <17b891c4161.11c0c97bc310170.8903332006418818543@ghanshyammann.com> ---- On Fri, 27 Aug 2021 09:37:55 -0500 Ghanshyam Mann wrote ---- > Hello Everyone, > > Tempest gate is blocked by tempest plugin sanity job which is failing > 100% for x/vmware-nsx-tempest-plugin issue. > > - https://zuul.opendev.org/t/openstack/builds?job_name=tempest-tox-plugin-sanity-check > > Please avoid recheck until the below patch to blacklist failing plugin is merged > - https://review.opendev.org/c/openstack/tempest/+/806411 It is merged, you can recheck now. -gmann > > -gmann > > From akanevsk at redhat.com Fri Aug 27 19:54:15 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 27 Aug 2021 15:54:15 -0400 Subject: [glance][interop] Yoga PTG request Message-ID: Glance, team, we would like to add a 20 minutes chat between Glance and Interop to discuss latest interop guidelines, and any changes in glance testing. Please, provide a pointer to etherpad and I will add it to the agenda. 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 rosmaita.fossdev at gmail.com Fri Aug 27 20:28:31 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Fri, 27 Aug 2021 16:28:31 -0400 Subject: [dev][cinder] Consultation about new cinder-backup features In-Reply-To: References: Message-ID: <94d4a481-f09d-f4c8-8008-babfdcd20702@gmail.com> On 8/27/21 1:59 PM, Daniel de Oliveira Pereira wrote: [snip] > Could you please let us know your thoughts about these features and if > you would be open to adding them to upstream Cinder? If yes, we would be > willing to submit the specs and work on the upstream implementation, if > they are approved. This sounds like a good PTG discussion topic. You can add it to the planning etherpad here: https://etherpad.opendev.org/p/yoga-ptg-cinder-planning There's also info about the dates and times we'll be meeting on that etherpad. > > Regards, > Daniel Pereira > From wodel.youchi at gmail.com Fri Aug 27 22:40:36 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Fri, 27 Aug 2021 23:40:36 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> Message-ID: Hi again, I redid my deployment from scratch, I reinstalled my undercloud and prepared the network template. Then I started the baremetal provisioning again, and I get this error: Deploy attempt failed on node computeHCI0 (UUID > 1d536020-50d6-43b6-9be4-1e5f60fa27d4), cleaning up\nTraceback (most recent > call last):\n File \"/usr/lib/python3.6/site-pack > ages/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(unex > pected))\nmetalsmith.exceptions.InvalidNIC: *Unexpected fields for a > network: subnet*\nDeploy attempt failed on node computeHCI2 (UUID > 0932aeac-e72c-4047-8c6b-c8fff674b0f3), cleaning up\nTrac > eback (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-pa > ckages/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 _ge > t_network\n 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields > for a network: subnet\nDeploy attempt failed on node contr > oller1 (UUID 8e4eb00b-6c34-4dcd-a9a5-aef3d9ec6c0a), cleaning up\nTraceback > (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in pro > vision_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 > \"/us > r/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: Unexpec > ted fields for a network: subnet\nDeploy attempt failed on node > controller0 (UUID 8f794261-53c1-4516-aa51-11bee6d887e8), cleaning > up\nTraceback (most recent call last):\n File \"/usr/lib/p > ython3.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 32e591a3-d598-43aa-ac05-b646eecef073), > 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 fa > iled on node computeHCI1 (UUID bf283f08-bef1-4f63-8bcd-d3c518c22e36), > 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(ni > c)))\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.I > nvalidNIC: Unexpected fields for a network: subnet\n", > > > "msg": "Unexpected fields for a network: subnet" > Here is my modified bonds_vlan.j2 file --- > {% set mtu_ctlplane_list = [ctlplane_mtu] %} > {% set mtu_dataplane_list = [] %} > {% for network in role_networks %} > {% if network.startswith('Tenant') %} > {{ mtu_dataplane_list.append(lookup('vars', networks_lower[network] ~ > '_mtu')) }} > {% else %} > {{ mtu_ctlplane_list.append(lookup('vars', networks_lower[network] ~ > '_mtu')) }} > {%- endif %} > {%- endfor %} > {% set min_viable_mtu_ctlplane = mtu_ctlplane_list | max %} > {% set min_viable_mtu_dataplane = mtu_dataplane_list | max %} > network_config: > - type: interface > name: nic1 > mtu: {{ ctlplane_mtu }} > use_dhcp: false > addresses: > - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }} > routes: {{ ctlplane_host_routes }} > - type: ovs_bridge > name: br1str > dns_servers: {{ ctlplane_dns_nameservers }} > domain: {{ dns_search_domains }} > members: > - type: ovs_bond > name: bond-str > mtu: {{ min_viable_mtu_dataplane }} > bonding_options: {{ bond_interface_ovs_options }} > members: > - type: interface > name: nic2 > mtu: {{ min_viable_mtu_dataplane }} > primary: true > - type: interface > name: nic3 > mtu: {{ min_viable_mtu_dataplane }} > {% for network in role_networks if network* not in ["External", "Tenant", > "InternalApi"] %} * > - type: vlan > device: bond-str > mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} > vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} > addresses: > - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ > lookup('vars', networks_lower[network] ~ '_cidr') }} > routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} > {% endfor %} > - type: ovs_bridge > name: {{ neutron_physical_bridge_name }} > dns_servers: {{ ctlplane_dns_nameservers }} > members: > - type: ovs_bond > name: bond-data > mtu: {{ min_viable_mtu_dataplane }} > bonding_options: {{ bond_interface_ovs_options }} > members: > - type: interface > name: nic4 > mtu: {{ min_viable_mtu_dataplane }} > primary: true > - type: interface > name: nic5 > mtu: {{ min_viable_mtu_dataplane }} > {% for network in role_networks if network *in ["External", "Tenant", > "InternalApi"] %}* > - type: vlan > device: bond-data > mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} > vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} > addresses: > - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ > lookup('vars', networks_lower[network] ~ '_cidr') }} > routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} > {%- endfor %} > > > Could someone help me understand where have I made mistakes? In my setup I use 5 nics : - 1 nic for provisioning - nic 2 and 3 : bonded for storage and storage management - nic 4 and 5 : bonded for tenant, api and external Here is my baremetal file > - name: Controller > count: 3 > defaults: > networks: > - network: ctlplane > subnet: ctlplane_subnet > vif: true > - network: external > subnet: external_subnet > - network: internal_api > subnet: internal_api_subnet > - network: storage > subnet: storage_subnet > - network: storage_mgmt > subnet: storage_mgmt_subnet > - network: tenant > subnet: tenant_subnet > network_config: > template: /home/stack/templates/nic-configs/bonds_vlans.j2 > bond_interface_ovs_options: bond_mode=active-backup > default_route_network: > - external > - name: ComputeHCI > count: 3 > defaults: > networks: > - network: ctlplane > subnet: ctlplane_subnet > vif: true > - network: external > subnet: external_subnet > - network: internal_api > subnet: internal_api_subnet > - network: storage > subnet: storage_subnet > - network: storage_mgmt > subnet: storage_mgmt_subnet > - network: tenant > subnet: tenant_subnet > network_config: > template: /home/stack/templates/nic-configs/bonds_vlans.j2 > bond_interface_ovs_options: bond_mode=active-backup > default_route_network: > - external > And here is my network_data file - name: Storage > name_lower: storage > vip: true > mtu: 1500 > subnets: > storage_subnet: > ip_subnet: 10.100.8.0/24 > allocation_pools: > - start: 10.100.8.150 > end: 10.100.8.250 > vlan: 1108 > - name: StorageMgmt > name_lower: storage_mgmt > vip: true > mtu: 1500 > subnets: > storage_mgmt_subnet: > ip_subnet: 10.100.7.0/24 > allocation_pools: > - start: 10.100.7.150 > end: 10.100.7.250 > vlan: 1107 > - name: InternalApi > name_lower: internal_api > vip: true > mtu: 1500 > subnets: > internal_api_subnet: > ip_subnet: 10.100.5.0/24 > allocation_pools: > - start: 10.100.5.150 > end: 10.100.5.250 > vlan: 1105 > - name: Tenant > vip: false # Tenant network does not use VIPs > mtu: 1500 > name_lower: tenant > subnets: > tenant_subnet: > ip_subnet: 10.100.6.0/24 > allocation_pools: > - start: 10.100.6.150 > end: 10.100.6.250 > vlan: 1106 > - name: External > name_lower: external > vip: true > mtu: 1500 > subnets: > external_subnet: > ip_subnet: 10.1.0.0/24 > allocation_pools: > - start: 10.1.0.10 > end: 10.1.0.200 > gateway_ip: 10.1.0.1 > vlan: 2100 > Thanks in advance Regards. Le mer. 25 août 2021 à 13:38, wodel youchi a écrit : > Hi and thanks > > I disabled the hide variable, and executed the command again, and this is > the result : > > 2021-08-25 13:27:21.834140 | 52540075-9baf-e9c1-3396-0000000000a0 | >> FATAL | Render network_config from template | computehci-1 | error={ >> >> "changed": false, >> >> >> * "msg": "AnsibleUndefinedVariable: 'bond_interface_ovs_options' is >> undefined" * >> >> } >> > > I understand that this is a variable, but I don't see where it is being > loaded from. > I have a *network-environment-overrides.yaml* file which contains this : > > parameter_defaults: >> ControllerNetworkConfigTemplate: >> '/home/stack/templates/nic-configs/bonds_vlans.j2' >> CephStorageNetworkConfigTemplate: >> '/home/stack/templates/nic-configs/bonds_vlans.j2' >> ComputeNetworkConfigTemplate: >> '/home/stack/templates/nic-configs/bonds_vlans.j2' >> >> NeutronNetworkVLANRanges: 'datacentre:1:100,provider:400:1000' >> NeutronExternalNetworkBridge: "''" >> NeutronNetworkType: 'vlan,flat' >> *BondInterfaceOvsOptions: "bond_mode=active-backup"* >> > > But I don't see how to connect them? > > > Regards. > > Le mer. 25 août 2021 à 09:08, Harald Jensas a écrit : > >> On 8/24/21 7:07 PM, wodel youchi wrote: >> > *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 | >> > FATAL | Render network_config from template | computehci-1 | >> > error={ >> > "censored": "the output has been hidden due to the fact that >> > 'no_log: true' was specified for this result", >> > "changed": false >> > } >> >> This looks like a problem with your nic config template, >> /home/stack/templates/nic-configs/bonds_vlans.j2. To debug disable >> "hideing" of sensitive logs. >> >> sudo sed -i 's/tripleo_network_config_hide_sensitive_logs: >> true/tripleo_network_config_hide_sensitive_logs: false/g' >> /usr/share/ansible/roles/tripleo-network-config/defaults/main.yml >> >> >> -- >> Harald >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Fri Aug 27 22:56:12 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Fri, 27 Aug 2021 18:56:12 -0400 Subject: [ci][nova] Server {uuid} failed to delete In-Reply-To: References: Message-ID: <8d537956-6def-95f0-935e-52c2b537dc9c@gmail.com> On 8/27/21 5:31 AM, Balazs Gibizer wrote: > > > On Fri, Aug 27, 2021 at 10:06, Balazs Gibizer > wrote: >> Hi, >> >> The gate is in a bad shape due to frequent failure of server delete >> tests due to placement conflicts. The bug that is tracked in [1] >> became more frequent after a recent placement feature (consumer_types) >> got landed. The nova team is aware of the situation and possible fixes >> are being discussed [2]. > > The patch [1] that supposed to fix the issue is approved and going > through the gate. > > [1] https://review.opendev.org/c/openstack/nova/+/688802 Looks like the patch ran into some difficulties and had to be revised. It's got a +1 from Zuul. If anyone's around who could approve it, that would be awesome. We're running into this issue in several different cinder CI jobs. thanks, brian > >> >> Cheers, >> gibi >> >> >> [1] http://status.openstack.org/elastic-recheck/#1836754 >> [2] https://review.opendev.org/q/topic:bug/1836754 >> >> >> >> > > > From mnaser at vexxhost.com Sat Aug 28 02:27:38 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 27 Aug 2021 22:27:38 -0400 Subject: [ci][nova] Server {uuid} failed to delete In-Reply-To: <8d537956-6def-95f0-935e-52c2b537dc9c@gmail.com> References: <8d537956-6def-95f0-935e-52c2b537dc9c@gmail.com> Message-ID: On Fri, Aug 27, 2021 at 6:59 PM Brian Rosmaita wrote: > On 8/27/21 5:31 AM, Balazs Gibizer wrote: > > > > > > On Fri, Aug 27, 2021 at 10:06, Balazs Gibizer > > wrote: > >> Hi, > >> > >> The gate is in a bad shape due to frequent failure of server delete > >> tests due to placement conflicts. The bug that is tracked in [1] > >> became more frequent after a recent placement feature (consumer_types) > >> got landed. The nova team is aware of the situation and possible fixes > >> are being discussed [2]. > > > > The patch [1] that supposed to fix the issue is approved and going > > through the gate. > > > > [1] https://review.opendev.org/c/openstack/nova/+/688802 > > Looks like the patch ran into some difficulties and had to be revised. > It's got a +1 from Zuul. If anyone's around who could approve it, that > would be awesome. We're running into this issue in several different > cinder CI jobs. > Perhaps you could add a Depends-On for those jobs in the meantime to unblock? > thanks, > brian > > > > >> > >> Cheers, > >> gibi > >> > >> > >> [1] http://status.openstack.org/elastic-recheck/#1836754 > >> [2] https://review.opendev.org/q/topic:bug/1836754 > >> > >> > >> > >> > > > > > > > > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Sat Aug 28 02:33:22 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 27 Aug 2021 22:33:22 -0400 Subject: RabbitMQ performance improvement for single-control node In-Reply-To: <20210827085244.Horde.VqwFS-QejCLzWRl1pfJtt9R@webmail.nde.ag> References: <20210827084759.Horde.DZPb-vFyM3ZJ52CXdmYHzVt@webmail.nde.ag> <20210827085244.Horde.VqwFS-QejCLzWRl1pfJtt9R@webmail.nde.ag> Message-ID: Do you actually need notifications to be enabled? If not, switch the driver to noop and make sure you purge the notification queues On Fri, Aug 27, 2021 at 4:56 AM Eugen Block wrote: > Sorry, I accidentally hit "send"...adding more information. > > # nova.conf > > [oslo_messaging_notifications] > driver = messagingv2 > [oslo_messaging_rabbit] > amqp_durable_queues = false > rabbit_ha_queues = false > ssl = false > heartbeat_timeout_threshold = 10 > > # neutron.conf > > [oslo_messaging_rabbit] > pool_max_size = 5000 > pool_max_overflow = 2000 > pool_timeout = 60 > > > These are the basics in the openstack services, I don't have access to > the rabbit.conf right now but I can add more information as soon as I > regain access to that machine. > > If there's anything else I can provide to improve the user experience > at least a bit please let me know. It would help a lot! > > Regards, > Eugen > > > Zitat von Eugen Block : > > > Hi *, > > > > I would greatly appreciate if anyone could help identifying some > > tweaks, if possible at all. > > > > This is a single control node environment with 19 compute nodes > > which are heavily used. It's still running on Pike and we won't be > > able to update until complete redeployment. > > I was able to improve the performance a lot by increasing the number > > of workers etc., but to me it seems the next bottleneck is rabbitmq. > > The rabbit process shows heavy CPU usage, almost constantly around > > 150% according to 'top' and I see heartbeat errors in the logs (e.g. > > cinder). Since there are so many config options I haven't touched > > them yet. Reading some of the tuning docs often refer to HA > > environments which is not the case here. > > > > I can paste some of the config snippets, maybe that already helps > > identifying anything: > > > > # nova.conf > > > > [oslo_messaging_rabbit] > > pool_max_size = 1600 > > pool_max_overflow = 1600 > > pool_timeout = 120 > > rpc_response_timeout = 120 > > rpc_conn_pool_size = 600 > > > > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Sat Aug 28 02:37:48 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 27 Aug 2021 22:37:48 -0400 Subject: [nova][dev] Improved scheduling error messages In-Reply-To: References: Message-ID: Hi there, I like the idea, but historically, Nova has steered away from giving more details on why things failed to schedule in order to prevent leaking information about the cloud. I agree that it’s one of the more painful errors, but I see the purpose behind masking it from the user in an environment where the user is not the operator. It would be good to hear from other devs, or maybe if this can be an admin-level thing. Thanks Mohammed On Wed, Aug 25, 2021 at 9:53 AM Brito, Hugo Nicodemos < Hugo.Brito at windriver.com> wrote: > Hi, > > In a prototype, we have improved Nova's scheduling error messages. > This helps both developers and end users better understand the > scheduler problems that occur on creation of an instance. > > When a scheduler error happens during instance creation via the nova > upstream, we get the following message on the Overview tab > (Horizon dashboard): "No valid host was found." This doesn't give us > enough information about what really happened, so our solution was to > add more details on the instance's overview page, e.g.: > > **Fault:Message** attribute provides a summary of why each host can not > satisfy the instance’s resource requirements, e.g. for controller-0, it > indicates “No valid host was found. Not enough host cell CPUs to fit > instance cell” (where cell is a numa-node or socket). > > **Fault:Details** attribute provides even more detail for each > individual host, for example it shows that the instance “required” 2 > CPU cores and shows the “actual” CPU cores available on each “numa” > node: “actual:0, numa:1” and “actual:1, numa:0”. > > These details are also present using the OpenStack CLI, in the > _fault_ attribute: > > - openstack server show > > With that in mind, we'd like to know if you are open to consider such > a change. We are willing to submit a spec and upstream that > implementation. > > Regards, > - nicodemos > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Sat Aug 28 02:40:20 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 27 Aug 2021 22:40:20 -0400 Subject: [horizon][dev] Multiple Login Sessions In-Reply-To: References: Message-ID: Horizon is just a Django app, you could use this: https://stackoverflow.com/questions/8408823/django-how-to-prevent-multiple-users-login-using-the-same-credentials Nothing stops someone from installing their own Horizon if they have direct access to the API though… On Wed, Aug 25, 2021 at 8:17 AM Soares Sarto, Ricardo < Ricardo.SoaresSarto at windriver.com> wrote: > Hi Everyone, > > Is there any feature to prevent multiple login sessions for the > same user in Horizon? > > That feature could be used to block a second login attempt for the > same user when another session already exists or invalidate the > the first session right after a second session is opened by the user. > > Any reference documentation would be very helpful. > > Kind regards, > rsoaress > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Sat Aug 28 02:42:54 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 27 Aug 2021 22:42:54 -0400 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: AFAIK, Magnum does not control what encapsulation type is being used. Is there a chance you have “vlan” inside tenant_network_types ? On Tue, Aug 24, 2021 at 12:05 AM Karera Tony wrote: > Hello Team, > > I was able to deploy Openstack with Magnum and Zun enabled. > > Unfortunately, When I create a cluster, Heat configure the fix/_network > for the nodes with Vlan and the nodes fail to get IPs. > > I was wondering if it is possible to trick the heat templates to create > vxlan network instead of vlan. > > Regards > > Tony Karera > > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Sat Aug 28 06:09:56 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Sat, 28 Aug 2021 14:09:56 +0800 Subject: Why the mariadb container always restart ? In-Reply-To: References: <003201d79b62$1bca9300$535fb900$@163.com> Message-ID: <006e01d79bd3$54378b50$fca6a1f0$@163.com> Should I execute it on the deployment node? Will it be executed when the mariadb docker container is started or when it is closed? -----Original Message----- From: Radosław Piliszek Sent: Saturday, August 28, 2021 1:06 AM To: Tommy Sway Cc: openstack-discuss Subject: Re: Why the mariadb container always restart ? On Fri, Aug 27, 2021 at 6:56 PM Tommy Sway wrote: > > Hi: > > > > The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. > > > > Ant this is the log : > > > > > > 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend > connection: 110: failed to reach primary view: 110 (Connection timed > out) > > at gcomm/src/pc.cpp:connect():160 > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend > connection: -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: > Failed to open channel 'openstack' at > 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 > (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection > timed out > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4 > 567) failed: 7 > > 2021-08-28 0:35:03 0 [ERROR] Aborting > > > > 210828 00:35:05 mysqld_safe mysqld from pid file > /var/lib/mysql/mariadb.pid ended > > 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from > /var/lib/mysql/ > > 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' > > 210828 00:35:12 mysqld_safe WSREP: Recovered position > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, > skipping position init > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' > > 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. > > 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. > > 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = > /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; > cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; > evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = > PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = > PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; > evs.send_window = 4; evs.stats_report_period = PT1M; > evs.suspect_timeout = PT5S; evs.user_send_window = 2; > evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; > gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = > /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover > = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; > gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; > gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; > gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = > 0.25; gcs.sync_donor = no; gmcast.listen_addr = > tcp://10.10.10.63:4567; gmcast.segment = 0; gmc > > 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for > certification: 140403, protocol version: -1 > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() > > 2021-08-28 0:35:12 0 [Note] WSREP: Start replication > > 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. > > 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority > set to other:0 > > 2021-08-28 0:35:12 0 [Warning] WSREP: access > file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) > > 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed > > 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') multicast: , ttl: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to b1ae23e3 > tcp://10.10.10.62:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to c296912b > tcp://10.10.10.61:4567 > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at > tcp://10.10.10.62:4567 stable > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at > tcp://10.10.10.61:4567 stable > > 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, > prim not possible > > > > > > What’s matter with it ? > > After lights-out, you have to run ``kolla-ansible mariadb_recovery`` to safely recover the Galera cluster state. -yoctozepto From tonykarera at gmail.com Sat Aug 28 06:17:34 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sat, 28 Aug 2021 08:17:34 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello Mohammed' Thanks a lot, actually i agree with you because as per the documentation.. kuryr understands vlans but unfortunately whenever i create inside vlan networks and attach an instance. The instance doesnt get an IP. I dont know if there is something i need change i the ml2_conf file. On Sat, 28 Aug 2021, 04:43 Mohammed Naser, wrote: > AFAIK, Magnum does not control what encapsulation type is being used. > > Is there a chance you have “vlan” inside tenant_network_types ? > > On Tue, Aug 24, 2021 at 12:05 AM Karera Tony wrote: > >> Hello Team, >> >> I was able to deploy Openstack with Magnum and Zun enabled. >> >> Unfortunately, When I create a cluster, Heat configure the fix/_network >> for the nodes with Vlan and the nodes fail to get IPs. >> >> I was wondering if it is possible to trick the heat templates to create >> vxlan network instead of vlan. >> >> Regards >> >> Tony Karera >> >> >> -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Sat Aug 28 06:59:28 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Sat, 28 Aug 2021 14:59:28 +0800 Subject: Why the mariadb container always restart ? In-Reply-To: References: <003201d79b62$1bca9300$535fb900$@163.com> Message-ID: <007201d79bda$3f52b640$bdf822c0$@163.com> It looks effect. But cannot access mariadb from the vip address, should I restart which container ? TASK [mariadb : Wait for master mariadb] ********************************************************************************************************************************************** skipping: [control02] skipping: [control03] FAILED - RETRYING: Wait for master mariadb (10 retries left). ok: [control01] TASK [mariadb : Wait for MariaDB service to be ready through VIP] ********************************************************************************************************************* FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control02]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:01.409807", "end": "2021-08-28 14:57:14.332713", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:12.922906", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control01]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.553486", "end": "2021-08-28 14:57:29.130631", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:25.577145", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} fatal: [control03]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.549868", "end": "2021-08-28 14:57:30.885324", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:27.335456", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} PLAY RECAP **************************************************************************************************************************************************************************** control01 : ok=30 changed=8 unreachable=0 failed=1 skipped=16 rescued=0 ignored=0 control02 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 control03 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 Command failed ansible-playbook -i ./multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /venv/share/kolla-ansible/ansible/mariadb_recovery.yml [root at control02 ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c2d0521d9833 10.10.10.113:4000/kolla/centos-binary-mariadb-server:wallaby "dumb-init -- kolla_…" 4 minutes ago Up 4 minutes mariadb 7f4038b89518 10.10.10.113:4000/kolla/centos-binary-horizon:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) horizon 82f8e756b5da 10.10.10.113:4000/kolla/centos-binary-heat-engine:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_engine 124d292e17d9 10.10.10.113:4000/kolla/centos-binary-heat-api-cfn:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api_cfn 75f6bebed35a 10.10.10.113:4000/kolla/centos-binary-heat-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api c8fc3fc49fe0 10.10.10.113:4000/kolla/centos-binary-neutron-server:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) neutron_server 1ed052094fde 10.10.10.113:4000/kolla/centos-binary-nova-novncproxy:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) nova_novncproxy b25403743c4b 10.10.10.113:4000/kolla/centos-binary-nova-conductor:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_conductor f150ff15e53a 10.10.10.113:4000/kolla/centos-binary-nova-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) nova_api c71b1718c4d8 10.10.10.113:4000/kolla/centos-binary-nova-scheduler:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_scheduler 8a5d43ac62ca 10.10.10.113:4000/kolla/centos-binary-placement-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) placement_api f0c142d683bf 10.10.10.113:4000/kolla/centos-binary-keystone:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone 6decd0fb670c 10.10.10.113:4000/kolla/centos-binary-keystone-fernet:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes keystone_fernet b2b8b14c114b 10.10.10.113:4000/kolla/centos-binary-keystone-ssh:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone_ssh f119c52904f9 10.10.10.113:4000/kolla/centos-binary-rabbitmq:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes rabbitmq e57493e8a877 10.10.10.113:4000/kolla/centos-binary-memcached:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes memcached bcb4f5a0f4a9 10.10.10.113:4000/kolla/centos-binary-mariadb-clustercheck:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes mariadb_clustercheck 6b7ffe32799c 10.10.10.113:4000/kolla/centos-binary-cron:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes cron ccd2b7c0d212 10.10.10.113:4000/kolla/centos-binary-kolla-toolbox:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes kolla_toolbox cf4ec99b9c59 10.10.10.113:4000/kolla/centos-binary-fluentd:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes fluentd -----Original Message----- From: Radosław Piliszek Sent: Saturday, August 28, 2021 1:06 AM To: Tommy Sway Cc: openstack-discuss Subject: Re: Why the mariadb container always restart ? On Fri, Aug 27, 2021 at 6:56 PM Tommy Sway wrote: > > Hi: > > > > The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. > > > > Ant this is the log : > > > > > > 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend > connection: 110: failed to reach primary view: 110 (Connection timed > out) > > at gcomm/src/pc.cpp:connect():160 > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend > connection: -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: > Failed to open channel 'openstack' at > 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 > (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection > timed out > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4 > 567) failed: 7 > > 2021-08-28 0:35:03 0 [ERROR] Aborting > > > > 210828 00:35:05 mysqld_safe mysqld from pid file > /var/lib/mysql/mariadb.pid ended > > 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from > /var/lib/mysql/ > > 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' > > 210828 00:35:12 mysqld_safe WSREP: Recovered position > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, > skipping position init > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' > > 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. > > 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. > > 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = > /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; > cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; > evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = > PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = > PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; > evs.send_window = 4; evs.stats_report_period = PT1M; > evs.suspect_timeout = PT5S; evs.user_send_window = 2; > evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; > gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = > /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover > = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; > gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; > gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; > gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = > 0.25; gcs.sync_donor = no; gmcast.listen_addr = > tcp://10.10.10.63:4567; gmcast.segment = 0; gmc > > 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for > certification: 140403, protocol version: -1 > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() > > 2021-08-28 0:35:12 0 [Note] WSREP: Start replication > > 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. > > 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority > set to other:0 > > 2021-08-28 0:35:12 0 [Warning] WSREP: access > file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) > > 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed > > 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') multicast: , ttl: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to b1ae23e3 > tcp://10.10.10.62:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to c296912b > tcp://10.10.10.61:4567 > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at > tcp://10.10.10.62:4567 stable > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at > tcp://10.10.10.61:4567 stable > > 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, > prim not possible > > > > > > What’s matter with it ? > > After lights-out, you have to run ``kolla-ansible mariadb_recovery`` to safely recover the Galera cluster state. -yoctozepto From sz_cuitao at 163.com Sat Aug 28 07:12:48 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Sat, 28 Aug 2021 15:12:48 +0800 Subject: Why the mariadb container always restart ? In-Reply-To: <007201d79bda$3f52b640$bdf822c0$@163.com> References: <003201d79b62$1bca9300$535fb900$@163.com> <007201d79bda$3f52b640$bdf822c0$@163.com> Message-ID: <007401d79bdc$1bf35040$53d9f0c0$@163.com> OK, I have resolved it. Thanks. -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Saturday, August 28, 2021 2:59 PM To: 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: Why the mariadb container always restart ? It looks effect. But cannot access mariadb from the vip address, should I restart which container ? TASK [mariadb : Wait for master mariadb] ********************************************************************************************************************************************** skipping: [control02] skipping: [control03] FAILED - RETRYING: Wait for master mariadb (10 retries left). ok: [control01] TASK [mariadb : Wait for MariaDB service to be ready through VIP] ********************************************************************************************************************* FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control02]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:01.409807", "end": "2021-08-28 14:57:14.332713", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:12.922906", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control01]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.553486", "end": "2021-08-28 14:57:29.130631", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:25.577145", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} fatal: [control03]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.549868", "end": "2021-08-28 14:57:30.885324", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:27.335456", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} PLAY RECAP **************************************************************************************************************************************************************************** control01 : ok=30 changed=8 unreachable=0 failed=1 skipped=16 rescued=0 ignored=0 control02 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 control03 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 Command failed ansible-playbook -i ./multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /venv/share/kolla-ansible/ansible/mariadb_recovery.yml [root at control02 ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c2d0521d9833 10.10.10.113:4000/kolla/centos-binary-mariadb-server:wallaby "dumb-init -- kolla_…" 4 minutes ago Up 4 minutes mariadb 7f4038b89518 10.10.10.113:4000/kolla/centos-binary-horizon:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) horizon 82f8e756b5da 10.10.10.113:4000/kolla/centos-binary-heat-engine:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_engine 124d292e17d9 10.10.10.113:4000/kolla/centos-binary-heat-api-cfn:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api_cfn 75f6bebed35a 10.10.10.113:4000/kolla/centos-binary-heat-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api c8fc3fc49fe0 10.10.10.113:4000/kolla/centos-binary-neutron-server:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) neutron_server 1ed052094fde 10.10.10.113:4000/kolla/centos-binary-nova-novncproxy:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) nova_novncproxy b25403743c4b 10.10.10.113:4000/kolla/centos-binary-nova-conductor:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_conductor f150ff15e53a 10.10.10.113:4000/kolla/centos-binary-nova-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) nova_api c71b1718c4d8 10.10.10.113:4000/kolla/centos-binary-nova-scheduler:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_scheduler 8a5d43ac62ca 10.10.10.113:4000/kolla/centos-binary-placement-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) placement_api f0c142d683bf 10.10.10.113:4000/kolla/centos-binary-keystone:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone 6decd0fb670c 10.10.10.113:4000/kolla/centos-binary-keystone-fernet:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes keystone_fernet b2b8b14c114b 10.10.10.113:4000/kolla/centos-binary-keystone-ssh:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone_ssh f119c52904f9 10.10.10.113:4000/kolla/centos-binary-rabbitmq:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes rabbitmq e57493e8a877 10.10.10.113:4000/kolla/centos-binary-memcached:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes memcached bcb4f5a0f4a9 10.10.10.113:4000/kolla/centos-binary-mariadb-clustercheck:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes mariadb_clustercheck 6b7ffe32799c 10.10.10.113:4000/kolla/centos-binary-cron:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes cron ccd2b7c0d212 10.10.10.113:4000/kolla/centos-binary-kolla-toolbox:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes kolla_toolbox cf4ec99b9c59 10.10.10.113:4000/kolla/centos-binary-fluentd:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes fluentd -----Original Message----- From: Radosław Piliszek Sent: Saturday, August 28, 2021 1:06 AM To: Tommy Sway Cc: openstack-discuss Subject: Re: Why the mariadb container always restart ? On Fri, Aug 27, 2021 at 6:56 PM Tommy Sway wrote: > > Hi: > > > > The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. > > > > Ant this is the log : > > > > > > 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend > connection: 110: failed to reach primary view: 110 (Connection timed > out) > > at gcomm/src/pc.cpp:connect():160 > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend > connection: -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: > Failed to open channel 'openstack' at > 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 > (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection > timed out > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4 > 567) failed: 7 > > 2021-08-28 0:35:03 0 [ERROR] Aborting > > > > 210828 00:35:05 mysqld_safe mysqld from pid file > /var/lib/mysql/mariadb.pid ended > > 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from > /var/lib/mysql/ > > 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' > > 210828 00:35:12 mysqld_safe WSREP: Recovered position > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, > skipping position init > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' > > 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. > > 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. > > 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = > /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; > cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; > evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = > PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = > PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; > evs.send_window = 4; evs.stats_report_period = PT1M; > evs.suspect_timeout = PT5S; evs.user_send_window = 2; > evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; > gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = > /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover > = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; > gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; > gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; > gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = > 0.25; gcs.sync_donor = no; gmcast.listen_addr = > tcp://10.10.10.63:4567; gmcast.segment = 0; gmc > > 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for > certification: 140403, protocol version: -1 > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() > > 2021-08-28 0:35:12 0 [Note] WSREP: Start replication > > 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. > > 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority > set to other:0 > > 2021-08-28 0:35:12 0 [Warning] WSREP: access > file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) > > 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed > > 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') multicast: , ttl: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to b1ae23e3 > tcp://10.10.10.62:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to c296912b > tcp://10.10.10.61:4567 > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at > tcp://10.10.10.62:4567 stable > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at > tcp://10.10.10.61:4567 stable > > 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, > prim not possible > > > > > > What’s matter with it ? > > After lights-out, you have to run ``kolla-ansible mariadb_recovery`` to safely recover the Galera cluster state. -yoctozepto From tonykarera at gmail.com Sat Aug 28 07:23:26 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sat, 28 Aug 2021 09:23:26 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello MOHAMMED, This is the file I am using. stack at deployment:~$ cat /etc/kolla/config/neutron/ml2_conf.ini [ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vlan,flat mechanism_drivers = openvswitch,l2population [ml2_type_vlan] network_vlan_ranges = physnet1 [ml2_type_flat] flat_networks = physnet1 Is there something I need to change. Regards Tony Karera On Sat, Aug 28, 2021 at 8:17 AM Karera Tony wrote: > Hello Mohammed' > > Thanks a lot, actually i agree with you because as per the documentation.. > kuryr understands vlans but unfortunately whenever i create inside vlan > networks and attach an instance. The instance doesnt get an IP. I dont know > if there is something i need change i the ml2_conf file. > > On Sat, 28 Aug 2021, 04:43 Mohammed Naser, wrote: > >> AFAIK, Magnum does not control what encapsulation type is being used. >> >> Is there a chance you have “vlan” inside tenant_network_types ? >> >> On Tue, Aug 24, 2021 at 12:05 AM Karera Tony >> wrote: >> >>> Hello Team, >>> >>> I was able to deploy Openstack with Magnum and Zun enabled. >>> >>> Unfortunately, When I create a cluster, Heat configure the fix/_network >>> for the nodes with Vlan and the nodes fail to get IPs. >>> >>> I was wondering if it is possible to trick the heat templates to create >>> vxlan network instead of vlan. >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Sat Aug 28 08:24:58 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sat, 28 Aug 2021 10:24:58 +0200 Subject: Tenant vlan Network Issue Message-ID: Hello Team, Whenever I create an internal network with type vlan. The Instances don't get IPs but for external Network it's fine. Below is the etc/kolla/config/neutron/ml2_conf.ini file [ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vlan,flat mechanism_drivers = openvswitch,l2population [ml2_type_vlan] network_vlan_ranges = physnet1 [ml2_type_flat] flat_networks = physnet1 Is there something I need to change or I need to configure the interface differently Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Sat Aug 28 11:57:27 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Sat, 28 Aug 2021 19:57:27 +0800 Subject: Why the mariadb container always restart ? In-Reply-To: <007401d79bdc$1bf35040$53d9f0c0$@163.com> References: <003201d79b62$1bca9300$535fb900$@163.com> <007201d79bda$3f52b640$bdf822c0$@163.com> <007401d79bdc$1bf35040$53d9f0c0$@163.com> Message-ID: <007a01d79c03$dfa13d00$9ee3b700$@163.com> After I use the kola-ansible stop, the whole system is stopped. But when I try to restart it , I found that the containers are all disappeared! Should I recreated the system ? -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Saturday, August 28, 2021 3:13 PM To: 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: Why the mariadb container always restart ? OK, I have resolved it. Thanks. -----Original Message----- From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Saturday, August 28, 2021 2:59 PM To: 'Radosław Piliszek' Cc: 'openstack-discuss' Subject: RE: Why the mariadb container always restart ? It looks effect. But cannot access mariadb from the vip address, should I restart which container ? TASK [mariadb : Wait for master mariadb] ********************************************************************************************************************************************** skipping: [control02] skipping: [control03] FAILED - RETRYING: Wait for master mariadb (10 retries left). ok: [control01] TASK [mariadb : Wait for MariaDB service to be ready through VIP] ********************************************************************************************************************* FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (6 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (5 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (4 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (3 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (2 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control02]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:01.409807", "end": "2021-08-28 14:57:14.332713", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:12.922906", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} FAILED - RETRYING: Wait for MariaDB service to be ready through VIP (1 retries left). fatal: [control01]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.553486", "end": "2021-08-28 14:57:29.130631", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:25.577145", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} fatal: [control03]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.10.10.254", "-P", "3306", "-u", "root", "-pAMDGL9CThcBlIsJZyS6VZKLwqvz0BIGbj5PC00Lf", "-e", "show databases;"], "delta": "0:00:03.549868", "end": "2021-08-28 14:57:30.885324", "msg": "non-zero return code", "rc": 1, "start": "2021-08-28 14:57:27.335456", "stderr": "ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)", "stderr_lines": ["ERROR 2002 (HY000): Can't connect to MySQL server on '10.10.10.254' (115)"], "stdout": "", "stdout_lines": []} PLAY RECAP **************************************************************************************************************************************************************************** control01 : ok=30 changed=8 unreachable=0 failed=1 skipped=16 rescued=0 ignored=0 control02 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 control03 : ok=24 changed=5 unreachable=0 failed=1 skipped=21 rescued=0 ignored=0 Command failed ansible-playbook -i ./multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /venv/share/kolla-ansible/ansible/mariadb_recovery.yml [root at control02 ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c2d0521d9833 10.10.10.113:4000/kolla/centos-binary-mariadb-server:wallaby "dumb-init -- kolla_…" 4 minutes ago Up 4 minutes mariadb 7f4038b89518 10.10.10.113:4000/kolla/centos-binary-horizon:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) horizon 82f8e756b5da 10.10.10.113:4000/kolla/centos-binary-heat-engine:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_engine 124d292e17d9 10.10.10.113:4000/kolla/centos-binary-heat-api-cfn:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api_cfn 75f6bebed35a 10.10.10.113:4000/kolla/centos-binary-heat-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) heat_api c8fc3fc49fe0 10.10.10.113:4000/kolla/centos-binary-neutron-server:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) neutron_server 1ed052094fde 10.10.10.113:4000/kolla/centos-binary-nova-novncproxy:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) nova_novncproxy b25403743c4b 10.10.10.113:4000/kolla/centos-binary-nova-conductor:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_conductor f150ff15e53a 10.10.10.113:4000/kolla/centos-binary-nova-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) nova_api c71b1718c4d8 10.10.10.113:4000/kolla/centos-binary-nova-scheduler:wallaby "dumb-init --single-…" 2 days ago Up 1 second (health: starting) nova_scheduler 8a5d43ac62ca 10.10.10.113:4000/kolla/centos-binary-placement-api:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (unhealthy) placement_api f0c142d683bf 10.10.10.113:4000/kolla/centos-binary-keystone:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone 6decd0fb670c 10.10.10.113:4000/kolla/centos-binary-keystone-fernet:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes keystone_fernet b2b8b14c114b 10.10.10.113:4000/kolla/centos-binary-keystone-ssh:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes (healthy) keystone_ssh f119c52904f9 10.10.10.113:4000/kolla/centos-binary-rabbitmq:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes rabbitmq e57493e8a877 10.10.10.113:4000/kolla/centos-binary-memcached:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes memcached bcb4f5a0f4a9 10.10.10.113:4000/kolla/centos-binary-mariadb-clustercheck:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes mariadb_clustercheck 6b7ffe32799c 10.10.10.113:4000/kolla/centos-binary-cron:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes cron ccd2b7c0d212 10.10.10.113:4000/kolla/centos-binary-kolla-toolbox:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes kolla_toolbox cf4ec99b9c59 10.10.10.113:4000/kolla/centos-binary-fluentd:wallaby "dumb-init --single-…" 2 days ago Up 10 minutes fluentd -----Original Message----- From: Radosław Piliszek Sent: Saturday, August 28, 2021 1:06 AM To: Tommy Sway Cc: openstack-discuss Subject: Re: Why the mariadb container always restart ? On Fri, Aug 27, 2021 at 6:56 PM Tommy Sway wrote: > > Hi: > > > > The system is broken down for the power, and I restart the whole system, but the mariadb container always restart, about one minite restart once. > > > > Ant this is the log : > > > > > > 2021-08-28 0:34:51 0 [Note] WSREP: (a8e9005b, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:03 0 [ERROR] WSREP: failed to open gcomm backend > connection: 110: failed to reach primary view: 110 (Connection timed > out) > > at gcomm/src/pc.cpp:connect():160 > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend > connection: -110 (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: > Failed to open channel 'openstack' at > 'gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567': -110 > (Connection timed out) > > 2021-08-28 0:35:03 0 [ERROR] WSREP: gcs connect failed: Connection > timed out > > 2021-08-28 0:35:03 0 [ERROR] WSREP: > wsrep::connect(gcomm://10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4 > 567) failed: 7 > > 2021-08-28 0:35:03 0 [ERROR] Aborting > > > > 210828 00:35:05 mysqld_safe mysqld from pid file > /var/lib/mysql/mariadb.pid ended > > 210828 00:35:08 mysqld_safe Starting mysqld daemon with databases from > /var/lib/mysql/ > > 210828 00:35:08 mysqld_safe WSREP: Running position recovery with --disable-log-error --pid-file='/var/lib/mysql//control03-recover.pid' > > 210828 00:35:12 mysqld_safe WSREP: Recovered position > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Read nil XID from storage engines, > skipping position init > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' > > 2021-08-28 0:35:12 0 [Note] /usr/libexec/mysqld (mysqld 10.3.28-MariaDB-log) starting as process 258 ... > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_load(): Galera 3.32(rXXXX) by Codership Oy info at codership.com loaded successfully. > > 2021-08-28 0:35:12 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration. > > 2021-08-28 0:35:12 0 [Note] WSREP: Found saved state: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:-1, safe_to_bootstrap: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: Passing config to GCS: base_dir = > /var/lib/mysql/; base_host = 10.10.10.63; base_port = 4567; > cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; > evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = > PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = > PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; > evs.send_window = 4; evs.stats_report_period = PT1M; > evs.suspect_timeout = PT5S; evs.user_send_window = 2; > evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; > gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = > /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.recover > = no; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; > gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; > gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; > gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = > 0.25; gcs.sync_donor = no; gmcast.listen_addr = > tcp://10.10.10.63:4567; gmcast.segment = 0; gmc > > 2021-08-28 0:35:12 0 [Note] WSREP: GCache history reset: > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:0 -> > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: Assign initial position for > certification: 140403, protocol version: -1 > > 2021-08-28 0:35:12 0 [Note] WSREP: wsrep_sst_grab() > > 2021-08-28 0:35:12 0 [Note] WSREP: Start replication > > 2021-08-28 0:35:12 0 [Note] WSREP: Setting initial position to > 5bdd8d83-05a4-11ec-adfd-ae6e7e26deb9:140403 > > 2021-08-28 0:35:12 0 [Note] WSREP: protonet asio version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: Using CRC-32C for message checksums. > > 2021-08-28 0:35:12 0 [Note] WSREP: backend: asio > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm thread scheduling priority > set to other:0 > > 2021-08-28 0:35:12 0 [Warning] WSREP: access > file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory) > > 2021-08-28 0:35:12 0 [Note] WSREP: restore pc from disk failed > > 2021-08-28 0:35:12 0 [Note] WSREP: GMCast version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') listening at tcp://10.10.10.63:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') multicast: , ttl: 1 > > 2021-08-28 0:35:12 0 [Note] WSREP: EVS version 0 > > 2021-08-28 0:35:12 0 [Note] WSREP: gcomm: connecting to group 'openstack', peer '10.10.10.61:4567,10.10.10.62:4567,10.10.10.63:4567' > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to b1ae23e3 > tcp://10.10.10.62:4567 > > 2021-08-28 0:35:12 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') turning message relay requesting off > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, > 'tcp://10.10.10.63:4567') connection established to c296912b > tcp://10.10.10.61:4567 > > 2021-08-28 0:35:16 0 [Note] WSREP: (c05f5c52, 'tcp://10.10.10.63:4567') turning message relay requesting on, nonlive peers: > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring b1ae23e3 at > tcp://10.10.10.62:4567 stable > > 2021-08-28 0:35:18 0 [Note] WSREP: declaring c296912b at > tcp://10.10.10.61:4567 stable > > 2021-08-28 0:35:19 0 [Warning] WSREP: no nodes coming from prim view, > prim not possible > > > > > > What’s matter with it ? > > After lights-out, you have to run ``kolla-ansible mariadb_recovery`` to safely recover the Galera cluster state. -yoctozepto From mnaser at vexxhost.com Sat Aug 28 15:43:25 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Sat, 28 Aug 2021 11:43:25 -0400 Subject: Tenant vlan Network Issue In-Reply-To: References: Message-ID: Your issue is that tenant_network_types should be vxlan. On Sat, Aug 28, 2021 at 4:29 AM Karera Tony wrote: > Hello Team, > > Whenever I create an internal network with type vlan. > > The Instances don't get IPs but for external Network it's fine. > > > Below is the etc/kolla/config/neutron/ml2_conf.ini file > > > [ml2] > type_drivers = flat,vlan,vxlan > tenant_network_types = vlan,flat > mechanism_drivers = openvswitch,l2population > > [ml2_type_vlan] > network_vlan_ranges = physnet1 > [ml2_type_flat] > flat_networks = physnet1 > > Is there something I need to change or I need to configure the interface > differently > Regards > > Tony Karera > > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Sat Aug 28 16:07:07 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sat, 28 Aug 2021 18:07:07 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: Message-ID: How can i make them both vxlan and vlan On Sat, 28 Aug 2021, 17:43 Mohammed Naser, wrote: > Your issue is that tenant_network_types should be vxlan. > > On Sat, Aug 28, 2021 at 4:29 AM Karera Tony wrote: > >> Hello Team, >> >> Whenever I create an internal network with type vlan. >> >> The Instances don't get IPs but for external Network it's fine. >> >> >> Below is the etc/kolla/config/neutron/ml2_conf.ini file >> >> >> [ml2] >> type_drivers = flat,vlan,vxlan >> tenant_network_types = vlan,flat >> mechanism_drivers = openvswitch,l2population >> >> [ml2_type_vlan] >> network_vlan_ranges = physnet1 >> [ml2_type_flat] >> flat_networks = physnet1 >> >> Is there something I need to change or I need to configure the interface >> differently >> Regards >> >> Tony Karera >> >> >> -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Sat Aug 28 17:07:55 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sat, 28 Aug 2021 19:07:55 +0200 Subject: [kolla][operators] Critical regression in Wallaby Message-ID: Dear Operators of Kolla-based deployments, There is a critical regression in current Kolla Ansible Wallaby code that results in an environment that shuts down VMs on each libvirtd container stop or restart on non-cgroupsv2 distros (so CentOS, Ubuntu and Debian Buster but not Debian Bullseye). [1] The fix is already available. [2] Please apply it to your Kolla Ansible installation if you are using Wallaby. Do note the fix only applies after redeploying which means redeployment action will still trigger the buggy behaviour that once! What to do if you have already deployed Wallaby? First of all, make sure you don't accidentally take an action that stops nova_libvirt (including restarts: both manual and those applied by Kolla Ansible due to user-requested changes). Please apply the patch above but don't rush with redeploying! Redeploy each compute node separately (or in batches if you prefer) - using --limit commandline parameter - and always make sure you have first migrated relevant VMs out of the nodes that are going to get nova_libvirt restarted. This way you can safely fix an existing deployment. We will be working on improving the testing to avoid such issues in the future. Acknowledgements Thanks to Ignazio Cassano for noticing and reporting the issue. I have triaged and analysed it, proposing a fix afterwards. [1] https://bugs.launchpad.net/kolla-ansible/+bug/1941706 [2] https://review.opendev.org/c/openstack/kolla-ansible/+/806476 -yoctozepto From kira034 at 163.com Sun Aug 29 09:17:05 2021 From: kira034 at 163.com (Hongbin Lu) Date: Sun, 29 Aug 2021 17:17:05 +0800 (CST) Subject: [neutron] Bug deputy report - week of Aug 23th Message-ID: <365a071c.168e.17b9132b70d.Coremail.kira034@163.com> Hi, I was Neutron bug deputy last week. Below is the report: Critical: * https://bugs.launchpad.net/neutron/+bug/1940905 openstack-tox-py36-with-neutron-lib-master is broken Medium: * https://bugs.launchpad.net/neutron/+bug/1941537 Neutron Policy Engine issues with PUT/Update * https://bugs.launchpad.net/neutron/+bug/1941902 is_lsp_router_port() doesn't consider all router device owners Triaging In Progress: * https://bugs.launchpad.net/neutron/+bug/1940950 [ovn] neutron api worker gets overloaded processing chassis_private updates Best regards, Hongbin -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Aug 29 18:51:56 2021 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 29 Aug 2021 14:51:56 -0400 Subject: RabbitMQ performance improvement for single-control node In-Reply-To: References: Message-ID: Yes, notifications are biggest enemy of rabbitMQ, specially if you don’t purge time to time. Also increase time of stats collection for rabbitMQ monitor if you are using it. Sent from my iPhone > On Aug 27, 2021, at 10:34 PM, Mohammed Naser wrote: > >  > Do you actually need notifications to be enabled? If not, switch the driver to noop and make sure you purge the notification queues > >> On Fri, Aug 27, 2021 at 4:56 AM Eugen Block wrote: >> Sorry, I accidentally hit "send"...adding more information. >> >> # nova.conf >> >> [oslo_messaging_notifications] >> driver = messagingv2 >> [oslo_messaging_rabbit] >> amqp_durable_queues = false >> rabbit_ha_queues = false >> ssl = false >> heartbeat_timeout_threshold = 10 >> >> # neutron.conf >> >> [oslo_messaging_rabbit] >> pool_max_size = 5000 >> pool_max_overflow = 2000 >> pool_timeout = 60 >> >> >> These are the basics in the openstack services, I don't have access to >> the rabbit.conf right now but I can add more information as soon as I >> regain access to that machine. >> >> If there's anything else I can provide to improve the user experience >> at least a bit please let me know. It would help a lot! >> >> Regards, >> Eugen >> >> >> Zitat von Eugen Block : >> >> > Hi *, >> > >> > I would greatly appreciate if anyone could help identifying some >> > tweaks, if possible at all. >> > >> > This is a single control node environment with 19 compute nodes >> > which are heavily used. It's still running on Pike and we won't be >> > able to update until complete redeployment. >> > I was able to improve the performance a lot by increasing the number >> > of workers etc., but to me it seems the next bottleneck is rabbitmq. >> > The rabbit process shows heavy CPU usage, almost constantly around >> > 150% according to 'top' and I see heartbeat errors in the logs (e.g. >> > cinder). Since there are so many config options I haven't touched >> > them yet. Reading some of the tuning docs often refer to HA >> > environments which is not the case here. >> > >> > I can paste some of the config snippets, maybe that already helps >> > identifying anything: >> > >> > # nova.conf >> > >> > [oslo_messaging_rabbit] >> > pool_max_size = 1600 >> > pool_max_overflow = 1600 >> > pool_timeout = 120 >> > rpc_response_timeout = 120 >> > rpc_conn_pool_size = 600 >> >> >> >> > -- > Mohammed Naser > VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Mon Aug 30 05:18:24 2021 From: akekane at redhat.com (Abhishek Kekane) Date: Mon, 30 Aug 2021 10:48:24 +0530 Subject: [glance][interop] Yoga PTG request In-Reply-To: References: Message-ID: Hi Arkady, Thank you for reaching out. Here is the glance etherpad for Yoga PTG, https://etherpad.opendev.org/p/yoga-ptg-glance-planning Please let me know if you need anything else. Thanks & Best Regards, Abhishek Kekane On Sat, Aug 28, 2021 at 1:27 AM Arkady Kanevsky wrote: > Glance, team, > we would like to add a 20 minutes chat between Glance and Interop to > discuss latest interop guidelines, and any changes in glance testing. > Please, provide a pointer to etherpad and I will add it to the agenda. > 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 sz_cuitao at 163.com Mon Aug 30 05:37:20 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 30 Aug 2021 13:37:20 +0800 Subject: How to stop the whole system gracefully ? Message-ID: <00af01d79d61$1adb57d0$50920770$@163.com> My system is installed using kola-ansible. The database was inconsistent due to the last unexpected shutdown, and the system could not start normally, which was very troublesome. I would like to ask what command should be used to shut down the entire system gracefully in an emergency ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Aug 30 06:49:59 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 30 Aug 2021 08:49:59 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: Message-ID: <5528888.crQR7OUkfV@p1> Hi, You can use vlan as tenant network too. But You have to remember that vlan is provider network, which means that You need to have configured vlans on Your network infrastructure too. And in case of tenant network, Neutron will automatically allocate one of the vlan ids to the network as user don't have possibility to choose vlan id for network (at least that's default policy in Neutron). So, You should check what vlan id is used by such tenant network, check if this vlan is properly confiugred on Your switches and then, if all is good, check where exactly such dhcp requests are dropped (are they going from compute node? are packets comming to the node with dhcp agent?). Base on that You can narrow down where the issue can be. On sobota, 28 sierpnia 2021 18:07:07 CEST Karera Tony wrote: > How can i make them both vxlan and vlan > > On Sat, 28 Aug 2021, 17:43 Mohammed Naser, wrote: > > Your issue is that tenant_network_types should be vxlan. > > > > On Sat, Aug 28, 2021 at 4:29 AM Karera Tony wrote: > >> Hello Team, > >> > >> Whenever I create an internal network with type vlan. > >> > >> The Instances don't get IPs but for external Network it's fine. > >> > >> > >> Below is the etc/kolla/config/neutron/ml2_conf.ini file > >> > >> > >> [ml2] > >> type_drivers = flat,vlan,vxlan > >> tenant_network_types = vlan,flat > >> mechanism_drivers = openvswitch,l2population > >> > >> [ml2_type_vlan] > >> network_vlan_ranges = physnet1 > >> [ml2_type_flat] > >> flat_networks = physnet1 > >> > >> Is there something I need to change or I need to configure the interface > >> differently > >> Regards > >> > >> Tony Karera > >> > >> > >> -- > > > > Mohammed Naser > > VEXXHOST, Inc. -- 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 eblock at nde.ag Mon Aug 30 08:28:20 2021 From: eblock at nde.ag (Eugen Block) Date: Mon, 30 Aug 2021 08:28:20 +0000 Subject: RabbitMQ performance improvement for single-control node In-Reply-To: References: Message-ID: <20210830082820.Horde.BvuJ5xOKSVPjoJSAH41R2_T@webmail.nde.ag> Hi, thank you both for your helpful responses. There are no consumers for the notifications so I'm indeed wondering who enabled them since the default for this deployment method was alse "false". Anyway, I will disable notifications and purge the queues and hopefully see the load dropping on the control node. Thank you very much! Eugen Zitat von Satish Patel : > Yes, notifications are biggest enemy of rabbitMQ, specially if you > don’t purge time to time. Also increase time of stats collection for > rabbitMQ monitor if you are using it. > > Sent from my iPhone > >> On Aug 27, 2021, at 10:34 PM, Mohammed Naser wrote: >> >>  >> Do you actually need notifications to be enabled? If not, switch >> the driver to noop and make sure you purge the notification queues >> >>> On Fri, Aug 27, 2021 at 4:56 AM Eugen Block wrote: >>> Sorry, I accidentally hit "send"...adding more information. >>> >>> # nova.conf >>> >>> [oslo_messaging_notifications] >>> driver = messagingv2 >>> [oslo_messaging_rabbit] >>> amqp_durable_queues = false >>> rabbit_ha_queues = false >>> ssl = false >>> heartbeat_timeout_threshold = 10 >>> >>> # neutron.conf >>> >>> [oslo_messaging_rabbit] >>> pool_max_size = 5000 >>> pool_max_overflow = 2000 >>> pool_timeout = 60 >>> >>> >>> These are the basics in the openstack services, I don't have access to >>> the rabbit.conf right now but I can add more information as soon as I >>> regain access to that machine. >>> >>> If there's anything else I can provide to improve the user experience >>> at least a bit please let me know. It would help a lot! >>> >>> Regards, >>> Eugen >>> >>> >>> Zitat von Eugen Block : >>> >>> > Hi *, >>> > >>> > I would greatly appreciate if anyone could help identifying some >>> > tweaks, if possible at all. >>> > >>> > This is a single control node environment with 19 compute nodes >>> > which are heavily used. It's still running on Pike and we won't be >>> > able to update until complete redeployment. >>> > I was able to improve the performance a lot by increasing the number >>> > of workers etc., but to me it seems the next bottleneck is rabbitmq. >>> > The rabbit process shows heavy CPU usage, almost constantly around >>> > 150% according to 'top' and I see heartbeat errors in the logs (e.g. >>> > cinder). Since there are so many config options I haven't touched >>> > them yet. Reading some of the tuning docs often refer to HA >>> > environments which is not the case here. >>> > >>> > I can paste some of the config snippets, maybe that already helps >>> > identifying anything: >>> > >>> > # nova.conf >>> > >>> > [oslo_messaging_rabbit] >>> > pool_max_size = 1600 >>> > pool_max_overflow = 1600 >>> > pool_timeout = 120 >>> > rpc_response_timeout = 120 >>> > rpc_conn_pool_size = 600 >>> >>> >>> >>> >> -- >> Mohammed Naser >> VEXXHOST, Inc. From ignaziocassano at gmail.com Mon Aug 30 11:17:09 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 13:17:09 +0200 Subject: [kolla][wallaby] hacluster does not work anymore after update Message-ID: Hello All, I have just update kolla wallaby with images released 27 hours ago but hacluster stopped working with them. TASK [hacluster : Ensure stonith is disabled] fails On the first controller pacemaker.log reports: https://paste.openstack.org/show/808400/ I have not changed configurations bevort updating . Thanks Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Aug 30 12:19:22 2021 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Aug 2021 13:19:22 +0100 Subject: [nova][dev] Improved scheduling error messages In-Reply-To: References: Message-ID: On Fri, 2021-08-27 at 22:37 -0400, Mohammed Naser wrote: > Hi there, > > I like the idea, but historically, Nova has steered away from giving more > details on why things failed to schedule in order to prevent leaking > information about the cloud. > > I agree that it’s one of the more painful errors, but I see the purpose > behind masking it from the user in an environment where the user is not the > operator. yes it has been given as feedback in the past that for some cloud exposing a detailed error message would be see as a moderate security issue/infomation leak. > > It would be good to hear from other devs, or maybe if this can be an > admin-level thing. we do provide some addtional info to admins today. for example to no admins if there is an external error message from say libvirt we will not provide the details of the trace back but addmins will see the full error. the main way we provide addtional info to admins however is via log messages in the case of scheduling failure. most of that however happens at debug level. the proablem with adding more loggin also comes in the fac that it gets very very verbose for large clouds. > > Thanks > Mohammed > > On Wed, Aug 25, 2021 at 9:53 AM Brito, Hugo Nicodemos < > Hugo.Brito at windriver.com> wrote: > > > Hi, > > > > In a prototype, we have improved Nova's scheduling error messages. > > This helps both developers and end users better understand the > > scheduler problems that occur on creation of an instance. > > > > When a scheduler error happens during instance creation via the nova > > upstream, we get the following message on the Overview tab > > (Horizon dashboard): "No valid host was found." This doesn't give us > > enough information about what really happened, so our solution was to > > add more details on the instance's overview page, e.g.: > > > > **Fault:Message** attribute provides a summary of why each host can not > > satisfy the instance’s resource requirements, > > this has been tried in the past and is very expensive to implement. it signifciatly increase the memovy overhaed for multi create or large clouds. after all if you are shcuilng on 1000 nodes and only 100 of them end up beign valide we need to store the reason for why the request foails for 900 of them. if that was a multi create reqwust with 10 vms beign creat at once then we have to store that 10 times over finally we have to compose the 9000 node removed messages into a single reponce boday and retrun that to the user. > > e.g. for controller-0, it > > indicates “No valid host was found. Not enough host cell CPUs to fit > > instance cell” (where cell is a numa-node or socket). > > > > **Fault:Details** attribute provides even more detail for each > > individual host, for example it shows that the instance “required” 2 > > CPU cores and shows the “actual” CPU cores available on each “numa” > > node: “actual:0, numa:1” and “actual:1, numa:0”. so for each of the 9000 host removal messsages we would need to also dump the request spec effectivly and synstise the requirement that was impost by each filter then present the host info for you to validate(the host state object) and also include that in the fault details > > > > These details are also present using the OpenStack CLI, in the > > _fault_ attribute: > > > > - openstack server show and the expose the MBS of data in the server show. > > > > With that in mind, we'd like to know if you are open to consider such > > a change. We are willing to submit a spec and upstream that > > implementation. that really does not sound like somethign we coudl accept upstream it has been propsed before by windriver and reject in the past. if you have a design that will scale well and is configurable so that we can avoid leaking details about the host infrastucure to teh end user while stil provideing useful info to the admin i would be happy to review the nova spec proposal. the most recent work done on this topic was by chris friesen https://review.opendev.org/c/openstack/nova-specs/+/390116 we do know this can be a pain point and that it would be good to improve it but we need something that works for 1 vm and 10 host to 100 vms an 1000 hosts and is still comprehendabel and does not use all your ram in the process. > > > > Regards, > > - nicodemos > > From radoslaw.piliszek at gmail.com Mon Aug 30 12:29:51 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 30 Aug 2021 14:29:51 +0200 Subject: [kolla][wallaby] hacluster does not work anymore after update In-Reply-To: References: Message-ID: For posterity: cleaning up and redeploying helped. -yoctozepto On Mon, Aug 30, 2021 at 1:18 PM Ignazio Cassano wrote: > > Hello All, I have just update kolla wallaby with images released 27 hours ago but hacluster stopped working with them. > TASK [hacluster : Ensure stonith is disabled] fails > On the first controller pacemaker.log reports: > > https://paste.openstack.org/show/808400/ > > I have not changed configurations bevort updating . > > Thanks > > Ignazio From ignaziocassano at gmail.com Mon Aug 30 12:31:18 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 14:31:18 +0200 Subject: [kolla][wallaby] hacluster does not work anymore after update In-Reply-To: References: Message-ID: Yes, it worked for me. thanks Il giorno lun 30 ago 2021 alle ore 14:30 Radosław Piliszek < radoslaw.piliszek at gmail.com> ha scritto: > For posterity: cleaning up and redeploying helped. > > -yoctozepto > > On Mon, Aug 30, 2021 at 1:18 PM Ignazio Cassano > wrote: > > > > Hello All, I have just update kolla wallaby with images released 27 > hours ago but hacluster stopped working with them. > > TASK [hacluster : Ensure stonith is disabled] fails > > On the first controller pacemaker.log reports: > > > > https://paste.openstack.org/show/808400/ > > > > I have not changed configurations bevort updating . > > > > Thanks > > > > Ignazio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Aug 30 12:36:06 2021 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 30 Aug 2021 14:36:06 +0200 Subject: [largescale-sig] Next meeting: Sept 1st, 15utc Message-ID: <9d0c7f7b-c8cb-9cce-3cb9-0aba854a665d@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=20210901T15 A number of topics have already been added to the agenda, including discussing the topic 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 hberaud at redhat.com Mon Aug 30 14:23:36 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 30 Aug 2021 16:23:36 +0200 Subject: [release][heat][ironic][requirements][swift][OpenStackSDK][vitrage][barbican][heat][horizon][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables Message-ID: Hello teams Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Xena cycle: ansible-role-atos-hsm ansible-role-lunasa-hsm ansible-role-thales-hsm heat-agents horizon ironic-prometheus-exporter ironic-python-agent-builder ironic-ui ovn-octavia-provider patrole python-openstackclient requirements swift tempest vitrage-dashboard vitrage Those should be released ASAP, and in all cases before the week of 13 September, 2021, so that we have a release to include in the final Xena release. Thanks for your attention. -- 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 helena at openstack.org Mon Aug 30 15:40:19 2021 From: helena at openstack.org (helena at openstack.org) Date: Mon, 30 Aug 2021 10:40:19 -0500 (CDT) Subject: [PTLs][release] Xena Cycle Highlights Message-ID: <1630338019.206730602@apps.rackspace.com> Hello Everyone! The deadline for cycle highlights is just a few days away, on September 3 [1]. Please be sure to get those in. I look forward to seeing what all you all have accomplished this release! 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 docs And 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. Thanks :) -Helena Spease (hspease) [1] [ https://releases.openstack.org/xena/schedule.html ]( https://releases.openstack.org/xena/schedule.html ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Aug 30 15:46:43 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 17:46:43 +0200 Subject: [Kolla] update Message-ID: Hello, I would like to ask if the procedure I am using for update my kolla wallaby is correct. Every week new images are released so I execute the following steps: 1. Pull new images on my local registry 2 pull new images from my local registry to controllers and compute nodes 3 kolla-ansible deploy Are the above steps the correct way or I missed something? Must I clean something before deploying ? Thanks Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Mon Aug 30 13:22:31 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 30 Aug 2021 14:22:31 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> Message-ID: Hi again, I really need your help guys. I tried to use the default bond_vlans.j2 without any modification, and I got the same error : > "logging": "Deploy attempt failed on node computeHCI0 (UUID > 1d536020-50d6-43b6-9be4-1e5f60fa27d4), cleaning up\nTraceback (most r > ecent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in provision_node\n nics.vali > date()\n File \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", > line 60, in validate\n result.append(('network', self._ge > t_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 attemp > t failed on node computeHCI1 (UUID bf283f08-bef1-4f63-8bcd-d3c518c22e36), > 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/pyt > hon3.6/site-packages/metalsmith/_nics.py\", line 60, in validate\n > result.append(('network', self._get_network(nic)))\n File \"/u > sr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n 'Unexpected fields for a network: %s' % ', '.joi > n(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields for a > network: subnet\nDeploy attempt failed on node controller1 > (UUID 8e4eb00b-6c34-4dcd-a9a5-aef3d9ec6c0a), cleaning up\nTraceback (most > recent call last):\n File \"/usr/lib/python3.6/site-packag > es/metalsmith/_provisioner.py\", line 392, in provision_node\n > nics.validate()\n File \"/usr/lib/python3.6/site-packages/metalsmi > th/_nics.py\", line 60, in validate\n result.append(('network', > self._get_network(nic)))\n File \"/usr/lib/python3.6/site-package > s/metalsmith/_nics.py\", line 128, in _get_network\n 'Unexpected fields > for a network: %s' % ', '.join(unexpected))\nmetalsmith.ex > ceptions.InvalidNIC: Unexpected fields for a network: subnet\nDeploy > attempt failed on node computeHCI2 (UUID 0932aeac-e72c-4047-8c6b > -c8fff674b0f3), 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 va > lidate\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 > What am I missing ?????? Regards. Le ven. 27 août 2021 à 23:40, wodel youchi a écrit : > Hi again, > I redid my deployment from scratch, I reinstalled my undercloud and > prepared the network template. > Then I started the baremetal provisioning again, and I get this error: > > Deploy attempt failed on node computeHCI0 (UUID >> 1d536020-50d6-43b6-9be4-1e5f60fa27d4), cleaning up\nTraceback (most recent >> call last):\n File \"/usr/lib/python3.6/site-pack >> ages/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(unex >> pected))\nmetalsmith.exceptions.InvalidNIC: *Unexpected fields for a >> network: subnet*\nDeploy attempt failed on node computeHCI2 (UUID >> 0932aeac-e72c-4047-8c6b-c8fff674b0f3), cleaning up\nTrac >> eback (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-pa >> ckages/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 _ge >> t_network\n 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields >> for a network: subnet\nDeploy attempt failed on node contr >> oller1 (UUID 8e4eb00b-6c34-4dcd-a9a5-aef3d9ec6c0a), cleaning >> up\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, >> in pro >> vision_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 >> \"/us >> r/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: Unexpec >> ted fields for a network: subnet\nDeploy attempt failed on node >> controller0 (UUID 8f794261-53c1-4516-aa51-11bee6d887e8), cleaning >> up\nTraceback (most recent call last):\n File \"/usr/lib/p >> ython3.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 32e591a3-d598-43aa-ac05-b646eecef073), >> 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 fa >> iled on node computeHCI1 (UUID bf283f08-bef1-4f63-8bcd-d3c518c22e36), >> 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(ni >> c)))\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.I >> nvalidNIC: Unexpected fields for a network: subnet\n", >> >> >> "msg": "Unexpected fields for a network: subnet" >> > > Here is my modified bonds_vlan.j2 file > > --- >> {% set mtu_ctlplane_list = [ctlplane_mtu] %} >> {% set mtu_dataplane_list = [] %} >> {% for network in role_networks %} >> {% if network.startswith('Tenant') %} >> {{ mtu_dataplane_list.append(lookup('vars', networks_lower[network] ~ >> '_mtu')) }} >> {% else %} >> {{ mtu_ctlplane_list.append(lookup('vars', networks_lower[network] ~ >> '_mtu')) }} >> {%- endif %} >> {%- endfor %} >> {% set min_viable_mtu_ctlplane = mtu_ctlplane_list | max %} >> {% set min_viable_mtu_dataplane = mtu_dataplane_list | max %} >> network_config: >> - type: interface >> name: nic1 >> mtu: {{ ctlplane_mtu }} >> use_dhcp: false >> addresses: >> - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }} >> routes: {{ ctlplane_host_routes }} >> - type: ovs_bridge >> name: br1str >> dns_servers: {{ ctlplane_dns_nameservers }} >> domain: {{ dns_search_domains }} >> members: >> - type: ovs_bond >> name: bond-str >> mtu: {{ min_viable_mtu_dataplane }} >> bonding_options: {{ bond_interface_ovs_options }} >> members: >> - type: interface >> name: nic2 >> mtu: {{ min_viable_mtu_dataplane }} >> primary: true >> - type: interface >> name: nic3 >> mtu: {{ min_viable_mtu_dataplane }} >> {% for network in role_networks if network* not in ["External", >> "Tenant", "InternalApi"] %} * >> - type: vlan >> device: bond-str >> mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} >> vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} >> addresses: >> - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ >> lookup('vars', networks_lower[network] ~ '_cidr') }} >> routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} >> {% endfor %} >> - type: ovs_bridge >> name: {{ neutron_physical_bridge_name }} >> dns_servers: {{ ctlplane_dns_nameservers }} >> members: >> - type: ovs_bond >> name: bond-data >> mtu: {{ min_viable_mtu_dataplane }} >> bonding_options: {{ bond_interface_ovs_options }} >> members: >> - type: interface >> name: nic4 >> mtu: {{ min_viable_mtu_dataplane }} >> primary: true >> - type: interface >> name: nic5 >> mtu: {{ min_viable_mtu_dataplane }} >> {% for network in role_networks if network *in ["External", "Tenant", >> "InternalApi"] %}* >> - type: vlan >> device: bond-data >> mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} >> vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} >> addresses: >> - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ >> lookup('vars', networks_lower[network] ~ '_cidr') }} >> routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} >> {%- endfor %} >> >> >> > Could someone help me understand where have I made mistakes? In my setup > I use 5 nics : > - 1 nic for provisioning > - nic 2 and 3 : bonded for storage and storage management > - nic 4 and 5 : bonded for tenant, api and external > > Here is my baremetal file > >> - name: Controller >> count: 3 >> defaults: >> networks: >> - network: ctlplane >> subnet: ctlplane_subnet >> vif: true >> - network: external >> subnet: external_subnet >> - network: internal_api >> subnet: internal_api_subnet >> - network: storage >> subnet: storage_subnet >> - network: storage_mgmt >> subnet: storage_mgmt_subnet >> - network: tenant >> subnet: tenant_subnet >> network_config: >> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >> bond_interface_ovs_options: bond_mode=active-backup >> default_route_network: >> - external >> - name: ComputeHCI >> count: 3 >> defaults: >> networks: >> - network: ctlplane >> subnet: ctlplane_subnet >> vif: true >> - network: external >> subnet: external_subnet >> - network: internal_api >> subnet: internal_api_subnet >> - network: storage >> subnet: storage_subnet >> - network: storage_mgmt >> subnet: storage_mgmt_subnet >> - network: tenant >> subnet: tenant_subnet >> network_config: >> template: /home/stack/templates/nic-configs/bonds_vlans.j2 >> bond_interface_ovs_options: bond_mode=active-backup >> default_route_network: >> - external >> > > And here is my network_data file > > - name: Storage >> name_lower: storage >> vip: true >> mtu: 1500 >> subnets: >> storage_subnet: >> ip_subnet: 10.100.8.0/24 >> allocation_pools: >> - start: 10.100.8.150 >> end: 10.100.8.250 >> vlan: 1108 >> - name: StorageMgmt >> name_lower: storage_mgmt >> vip: true >> mtu: 1500 >> subnets: >> storage_mgmt_subnet: >> ip_subnet: 10.100.7.0/24 >> allocation_pools: >> - start: 10.100.7.150 >> end: 10.100.7.250 >> vlan: 1107 >> - name: InternalApi >> name_lower: internal_api >> vip: true >> mtu: 1500 >> subnets: >> internal_api_subnet: >> ip_subnet: 10.100.5.0/24 >> allocation_pools: >> - start: 10.100.5.150 >> end: 10.100.5.250 >> vlan: 1105 >> - name: Tenant >> vip: false # Tenant network does not use VIPs >> mtu: 1500 >> name_lower: tenant >> subnets: >> tenant_subnet: >> ip_subnet: 10.100.6.0/24 >> allocation_pools: >> - start: 10.100.6.150 >> end: 10.100.6.250 >> vlan: 1106 >> - name: External >> name_lower: external >> vip: true >> mtu: 1500 >> subnets: >> external_subnet: >> ip_subnet: 10.1.0.0/24 >> allocation_pools: >> - start: 10.1.0.10 >> end: 10.1.0.200 >> gateway_ip: 10.1.0.1 >> vlan: 2100 >> > > Thanks in advance > > Regards. > > Le mer. 25 août 2021 à 13:38, wodel youchi a > écrit : > >> Hi and thanks >> >> I disabled the hide variable, and executed the command again, and this is >> the result : >> >> 2021-08-25 13:27:21.834140 | 52540075-9baf-e9c1-3396-0000000000a0 | >>> FATAL | Render network_config from template | computehci-1 | error={ >>> >>> "changed": false, >>> >>> >>> * "msg": "AnsibleUndefinedVariable: 'bond_interface_ovs_options' is >>> undefined" * >>> >>> } >>> >> >> I understand that this is a variable, but I don't see where it is being >> loaded from. >> I have a *network-environment-overrides.yaml* file which contains this : >> >> parameter_defaults: >>> ControllerNetworkConfigTemplate: >>> '/home/stack/templates/nic-configs/bonds_vlans.j2' >>> CephStorageNetworkConfigTemplate: >>> '/home/stack/templates/nic-configs/bonds_vlans.j2' >>> ComputeNetworkConfigTemplate: >>> '/home/stack/templates/nic-configs/bonds_vlans.j2' >>> >>> NeutronNetworkVLANRanges: 'datacentre:1:100,provider:400:1000' >>> NeutronExternalNetworkBridge: "''" >>> NeutronNetworkType: 'vlan,flat' >>> *BondInterfaceOvsOptions: "bond_mode=active-backup"* >>> >> >> But I don't see how to connect them? >> >> >> Regards. >> >> Le mer. 25 août 2021 à 09:08, Harald Jensas a >> écrit : >> >>> On 8/24/21 7:07 PM, wodel youchi wrote: >>> > *2021-08-24 18:01:18.371725 | 52540075-9baf-8232-d4fa-0000000000a0 >>> | >>> > FATAL | Render network_config from template | computehci-1 | >>> > error={ >>> > "censored": "the output has been hidden due to the fact that >>> > 'no_log: true' was specified for this result", >>> > "changed": false >>> > } >>> >>> This looks like a problem with your nic config template, >>> /home/stack/templates/nic-configs/bonds_vlans.j2. To debug disable >>> "hideing" of sensitive logs. >>> >>> sudo sed -i 's/tripleo_network_config_hide_sensitive_logs: >>> true/tripleo_network_config_hide_sensitive_logs: false/g' >>> /usr/share/ansible/roles/tripleo-network-config/defaults/main.yml >>> >>> >>> -- >>> Harald >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Aug 30 16:15:30 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 18:15:30 +0200 Subject: [Kolla] update In-Reply-To: References: Message-ID: To be more clear: I wonder if kolla ansible detects the presence of new images version and makes all neeeded operations for restarting containers from them. Ignazio Il Lun 30 Ago 2021, 17:46 Ignazio Cassano ha scritto: > Hello, I would like to ask if the procedure I am using for update my kolla > wallaby is correct. > Every week new images are released so I execute the following steps: > > 1. Pull new images on my local registry > > 2 pull new images from my local registry to controllers and compute nodes > > 3 kolla-ansible deploy > > Are the above steps the correct way or I missed something? > Must I clean something before deploying ? > Thanks > > Ignazio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Aug 30 16:19:42 2021 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Aug 2021 17:19:42 +0100 Subject: [Kolla] update In-Reply-To: References: Message-ID: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > Hello, I would like to ask if the procedure I am using for update my kolla > wallaby is correct. > Every week new images are released so I execute the following steps: > > 1. Pull new images on my local registry > > 2 pull new images from my local registry to controllers and compute nodes > > 3 kolla-ansible deploy > > Are the above steps the correct way or I missed something? > Must I clean something before deploying ? > Thanks that is more or less what i have seen recommended in the past yes. you cna use deploy or reconfigure. in generall kolla-ansible upgrade is not needed unless you are doing a major version bump so in your case pulling the images then running deploy should simply replace the containers. one thing you are proably missing is removing unused un tagged images form the nodes. e.g. you will want to perodically remove the old images so that they disks dont fill up. you also proably want to add a staging step between 1 and 2 wheere you test thsi on a small test env first just to make sure there are no surpriese before pushing to production. > > Ignazio From pierre at stackhpc.com Mon Aug 30 16:28:18 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Mon, 30 Aug 2021 18:28:18 +0200 Subject: [Kolla] update In-Reply-To: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: On Mon, 30 Aug 2021 at 18:21, Sean Mooney wrote: > > On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > > Hello, I would like to ask if the procedure I am using for update my kolla > > wallaby is correct. > > Every week new images are released so I execute the following steps: > > > > 1. Pull new images on my local registry > > > > 2 pull new images from my local registry to controllers and compute nodes > > > > 3 kolla-ansible deploy > > > > Are the above steps the correct way or I missed something? > > Must I clean something before deploying ? > > Thanks > > that is more or less what i have seen recommended in the past yes. > > you cna use deploy or reconfigure. > in generall kolla-ansible upgrade is not needed unless you are doing a major version bump > so in your case pulling the images then running deploy should simply replace the containers. > > one thing you are proably missing is removing unused un tagged images form the nodes. > e.g. you will want to perodically remove the old images so that they disks dont fill up. > > you also proably want to add a staging step between 1 and 2 wheere you test thsi on a small test env first just to make sure there > are no surpriese before pushing to production. > > > > Ignazio Also worth mentioning that the Train release added the kolla-ansible deploy-containers command. From the release notes: This action will only do the container comparison and deploy out new containers if that comparison detects a change is needed. This should be used to get updated container images, where no new config changes are needed, deployed out quickly. But for a weekly update I would recommend using deploy or reconfigure, to make sure the configuration is updated if required. From ignaziocassano at gmail.com Mon Aug 30 16:31:04 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 18:31:04 +0200 Subject: [Kolla] update In-Reply-To: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: Hello Sean, I am agree to use a testing environment before running on production. I wonder if kolla detects the presence of new images and makes all needed steps for stopping containers and restarting from new images. I am new on docker. I am asking because in my last update I got same issues in hacluster and rabbitmq. I solved stopping, remove related containers and volumes and deploying again. Ignazio Il Lun 30 Ago 2021, 18:19 Sean Mooney ha scritto: > On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > > Hello, I would like to ask if the procedure I am using for update my > kolla > > wallaby is correct. > > Every week new images are released so I execute the following steps: > > > > 1. Pull new images on my local registry > > > > 2 pull new images from my local registry to controllers and compute nodes > > > > 3 kolla-ansible deploy > > > > Are the above steps the correct way or I missed something? > > Must I clean something before deploying ? > > Thanks > > that is more or less what i have seen recommended in the past yes. > > you cna use deploy or reconfigure. > in generall kolla-ansible upgrade is not needed unless you are doing a > major version bump > so in your case pulling the images then running deploy should simply > replace the containers. > > one thing you are proably missing is removing unused un tagged images form > the nodes. > e.g. you will want to perodically remove the old images so that they disks > dont fill up. > > you also proably want to add a staging step between 1 and 2 wheere you > test thsi on a small test env first just to make sure there > are no surpriese before pushing to production. > > > > Ignazio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Aug 30 16:33:53 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 18:33:53 +0200 Subject: [Kolla] update In-Reply-To: References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: Sorry: "some issues" not "same issues" Il Lun 30 Ago 2021, 18:31 Ignazio Cassano ha scritto: > Hello Sean, I am agree to use a testing environment before running on > production. > I wonder if kolla detects the presence of new images and makes all needed > steps for stopping containers and restarting from new images. > I am new on docker. > I am asking because in my last update I got same issues in hacluster and > rabbitmq. > I solved stopping, remove related containers and volumes and deploying > again. > Ignazio > > > Il Lun 30 Ago 2021, 18:19 Sean Mooney ha scritto: > >> On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: >> > Hello, I would like to ask if the procedure I am using for update my >> kolla >> > wallaby is correct. >> > Every week new images are released so I execute the following steps: >> > >> > 1. Pull new images on my local registry >> > >> > 2 pull new images from my local registry to controllers and compute >> nodes >> > >> > 3 kolla-ansible deploy >> > >> > Are the above steps the correct way or I missed something? >> > Must I clean something before deploying ? >> > Thanks >> >> that is more or less what i have seen recommended in the past yes. >> >> you cna use deploy or reconfigure. >> in generall kolla-ansible upgrade is not needed unless you are doing a >> major version bump >> so in your case pulling the images then running deploy should simply >> replace the containers. >> >> one thing you are proably missing is removing unused un tagged images >> form the nodes. >> e.g. you will want to perodically remove the old images so that they >> disks dont fill up. >> >> you also proably want to add a staging step between 1 and 2 wheere you >> test thsi on a small test env first just to make sure there >> are no surpriese before pushing to production. >> > >> > Ignazio >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Aug 30 16:41:44 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 18:41:44 +0200 Subject: [Kolla] update In-Reply-To: References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: Hello Pierre, thanks for your contribute. Please, check my last email. I need to be sure I understood well. Ignazio Il Lun 30 Ago 2021, 18:28 Pierre Riteau ha scritto: > On Mon, 30 Aug 2021 at 18:21, Sean Mooney wrote: > > > > On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > > > Hello, I would like to ask if the procedure I am using for update my > kolla > > > wallaby is correct. > > > Every week new images are released so I execute the following steps: > > > > > > 1. Pull new images on my local registry > > > > > > 2 pull new images from my local registry to controllers and compute > nodes > > > > > > 3 kolla-ansible deploy > > > > > > Are the above steps the correct way or I missed something? > > > Must I clean something before deploying ? > > > Thanks > > > > that is more or less what i have seen recommended in the past yes. > > > > you cna use deploy or reconfigure. > > in generall kolla-ansible upgrade is not needed unless you are doing a > major version bump > > so in your case pulling the images then running deploy should simply > replace the containers. > > > > one thing you are proably missing is removing unused un tagged images > form the nodes. > > e.g. you will want to perodically remove the old images so that they > disks dont fill up. > > > > you also proably want to add a staging step between 1 and 2 wheere you > test thsi on a small test env first just to make sure there > > are no surpriese before pushing to production. > > > > > > Ignazio > > Also worth mentioning that the Train release added the kolla-ansible > deploy-containers command. From the release notes: This action will > only do the container comparison and deploy out new containers if that > comparison detects a change is needed. This should be used to get > updated container images, where no new config changes are needed, > deployed out quickly. > > But for a weekly update I would recommend using deploy or reconfigure, > to make sure the configuration is updated if required. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Aug 30 16:51:16 2021 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Aug 2021 17:51:16 +0100 Subject: [Kolla] update In-Reply-To: References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: On Mon, 2021-08-30 at 18:31 +0200, Ignazio Cassano wrote: > Hello Sean, I am agree to use a testing environment before running on > production. > I wonder if kolla detects the presence of new images and makes all needed > steps for stopping containers and restarting from new images. if you are not changing the tag then no kolla wont see that the tag was updated on docker hub and pull the new images if you are building your own images and pushign them to a local registry with a new tag e.g. train-30-08-2021 and then you update the tag in your gloabl.yaml kolla will detech that that image is not avaiable local on the nodes, pull it and then update it. generally i would suggest when you pull the images to your local regestry you tag them your self with a new tag and then update the tag in your gloabl.yml so that you can roll back to the old images eaislly if you need too. > I am new on docker. > I am asking because in my last update I got same issues in hacluster and > rabbitmq. > I solved stopping, remove related containers and volumes and deploying > again. > Ignazio > > > Il Lun 30 Ago 2021, 18:19 Sean Mooney ha scritto: > > > On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > > > Hello, I would like to ask if the procedure I am using for update my > > kolla > > > wallaby is correct. > > > Every week new images are released so I execute the following steps: > > > > > > 1. Pull new images on my local registry > > > > > > 2 pull new images from my local registry to controllers and compute nodes > > > > > > 3 kolla-ansible deploy > > > > > > Are the above steps the correct way or I missed something? > > > Must I clean something before deploying ? > > > Thanks > > > > that is more or less what i have seen recommended in the past yes. > > > > you cna use deploy or reconfigure. > > in generall kolla-ansible upgrade is not needed unless you are doing a > > major version bump > > so in your case pulling the images then running deploy should simply > > replace the containers. > > > > one thing you are proably missing is removing unused un tagged images form > > the nodes. > > e.g. you will want to perodically remove the old images so that they disks > > dont fill up. > > > > you also proably want to add a staging step between 1 and 2 wheere you > > test thsi on a small test env first just to make sure there > > are no surpriese before pushing to production. > > > > > > Ignazio > > > > > > From ignaziocassano at gmail.com Mon Aug 30 16:55:06 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 30 Aug 2021 18:55:06 +0200 Subject: [Kolla] update In-Reply-To: References: <4a37dfb2625e9805be36a4b480dd5b9087492137.camel@redhat.com> Message-ID: It seems a good idea. Thanks Ignazio Il Lun 30 Ago 2021, 18:51 Sean Mooney ha scritto: > On Mon, 2021-08-30 at 18:31 +0200, Ignazio Cassano wrote: > > Hello Sean, I am agree to use a testing environment before running on > > production. > > I wonder if kolla detects the presence of new images and makes all needed > > steps for stopping containers and restarting from new images. > if you are not changing the tag then no kolla wont see that the tag was > updated on docker hub and pull the new images > > if you are building your own images and pushign them to a local registry > with a new tag e.g. train-30-08-2021 and then you > update the tag in your gloabl.yaml kolla will detech that that image is > not avaiable local on the nodes, pull it and then update it. > > generally i would suggest when you pull the images to your local regestry > you tag them your self with a new tag and then update > the tag in your gloabl.yml so that you can roll back to the old images > eaislly if you need too. > > > > I am new on docker. > > I am asking because in my last update I got same issues in hacluster and > > rabbitmq. > > I solved stopping, remove related containers and volumes and deploying > > again. > > Ignazio > > > > > > Il Lun 30 Ago 2021, 18:19 Sean Mooney ha scritto: > > > > > On Mon, 2021-08-30 at 17:46 +0200, Ignazio Cassano wrote: > > > > Hello, I would like to ask if the procedure I am using for update my > > > kolla > > > > wallaby is correct. > > > > Every week new images are released so I execute the following steps: > > > > > > > > 1. Pull new images on my local registry > > > > > > > > 2 pull new images from my local registry to controllers and compute > nodes > > > > > > > > 3 kolla-ansible deploy > > > > > > > > Are the above steps the correct way or I missed something? > > > > Must I clean something before deploying ? > > > > Thanks > > > > > > that is more or less what i have seen recommended in the past yes. > > > > > > you cna use deploy or reconfigure. > > > in generall kolla-ansible upgrade is not needed unless you are doing a > > > major version bump > > > so in your case pulling the images then running deploy should simply > > > replace the containers. > > > > > > one thing you are proably missing is removing unused un tagged images > form > > > the nodes. > > > e.g. you will want to perodically remove the old images so that they > disks > > > dont fill up. > > > > > > you also proably want to add a staging step between 1 and 2 wheere you > > > test thsi on a small test env first just to make sure there > > > are no surpriese before pushing to production. > > > > > > > > Ignazio > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfens98 at uvic.ca Mon Aug 30 16:27:30 2021 From: mfens98 at uvic.ca (Matthew Ens) Date: Mon, 30 Aug 2021 09:27:30 -0700 Subject: Hypervisors inaccessable with VM on provider network Message-ID: <996cad8d-2715-ef37-2ebe-d1a5e49b2024@uvic.ca> Hello, I am running openstack-victoria on centos8 without OVS and I have followed the installation directions according to the docs with the option to have self-service networks as our project does not need all our vm's accessible from the outside. We do still however occasionally use the provider network for users who need external access to the VM and in cases where using a floating ip is not sufficient. We noticed when there is a VM connected to the provider network we lose access to the hypervisor (cannot ssh or anything, ping still gives a response though) and the hypervisor itself loses internet access (cannot ping or curl some test website). We narrowed it down to two issues. One, we were using firewalld to keep track of our own firewall rules while openstack uses iptables to enforce its security group rules. These two did not work well together due to the second issue where openstack assigns incoming connections to a conntrack zone, it seemed like firewalld could not handle this correctly and would drop connections that should have been allowed under its rules. After transferring our firewall rules to iptables and masking firewalld, the hypervisor was accessible over ssh but could not access the internet due to our rule allowing ESTABLISHED and RELATED connections not being applied properly when a packet was assigned to a conntrack zone. The work around we found for this was to add a rule where packets destined for the hypervisor were not assigned to a conntrack zone (add a rule to the raw iptables table in the PREROUTING chain to just be accepted if the destination ip address was the address of the hypervisor). This worked until a new vm was created as openstack rebuilds the iptables when a change is made and puts it's own rules above those created by someone other than openstack. To fix this we changed the code in neutron (iptables_manager.py, the modify_rules function) to put this rule only above those made by openstack in the raw iptables table, PREROUTING chain. This fixed our issue, we are now able to access the hypervisor when VMs are running on a provider network and VMs and the hypervisor are accessible and able to access the internet. Security groups are also properly enforced on the VMs as are our firewall rules assigned elsewhere in iptables. I'm not sure if this is exactly a bug since in most cases openstack should be assigning its own firewall rules first in case there are DROP rules put in by someone else or I could also have missed some configuration step in which case I would love to know how I can improve. We thought others may be having a similar issue. If you'd like more details or have suggestions I'm happy to receive feedback. Cheers, Matt From balazs.gibizer at est.tech Mon Aug 30 19:48:49 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 30 Aug 2021 21:48:49 +0200 Subject: [ci][nova] Server {uuid} failed to delete In-Reply-To: References: <8d537956-6def-95f0-935e-52c2b537dc9c@gmail.com> Message-ID: The fix has been landed https://review.opendev.org/c/openstack/nova/+/688802 On Fri, Aug 27, 2021 at 22:27, Mohammed Naser wrote: > > > On Fri, Aug 27, 2021 at 6:59 PM Brian Rosmaita > wrote: >> On 8/27/21 5:31 AM, Balazs Gibizer wrote: >> > >> > >> > On Fri, Aug 27, 2021 at 10:06, Balazs Gibizer >> >> > wrote: >> >> Hi, >> >> >> >> The gate is in a bad shape due to frequent failure of server >> delete >> >> tests due to placement conflicts. The bug that is tracked in [1] >> >> became more frequent after a recent placement feature >> (consumer_types) >> >> got landed. The nova team is aware of the situation and possible >> fixes >> >> are being discussed [2]. >> > >> > The patch [1] that supposed to fix the issue is approved and going >> > through the gate. >> > >> > [1] https://review.opendev.org/c/openstack/nova/+/688802 >> >> Looks like the patch ran into some difficulties and had to be >> revised. >> It's got a +1 from Zuul. If anyone's around who could approve it, >> that >> would be awesome. We're running into this issue in several >> different >> cinder CI jobs. > > Perhaps you could add a Depends-On for those jobs in the meantime to > unblock? > >> >> thanks, >> brian >> >> > >> >> >> >> Cheers, >> >> gibi >> >> >> >> >> >> [1] http://status.openstack.org/elastic-recheck/#1836754 >> >> [2] https://review.opendev.org/q/topic:bug/1836754 >> >> >> >> >> >> >> >> >> > >> > >> > >> >> > -- > Mohammed Naser > VEXXHOST, Inc. From pierre at stackhpc.com Mon Aug 30 22:02:35 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Tue, 31 Aug 2021 00:02:35 +0200 Subject: [Kolla] update In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 at 17:48, Ignazio Cassano wrote: > > Hello, I would like to ask if the procedure I am using for update my kolla wallaby is correct. > Every week new images are released so I execute the following steps: > > 1. Pull new images on my local registry > > 2 pull new images from my local registry to controllers and compute nodes > > 3 kolla-ansible deploy > > Are the above steps the correct way or I missed something? > Must I clean something before deploying ? > Thanks > > Ignazio This approach is correct. Step 2 will ensure `kolla-ansible deploy` knows that new images are available. You can verify it yourself: after executing step 2, run `docker ps` on your nodes and you should see containers running from images identified only by an ID. This is because the tag (for example wallaby) references the new image. However, as Sean said, changing the tag each time you redeploy will allow you to revert to previous container images if anything went bad. Additionally, it would allow you to skip step 2, since the deploy command will automatically pull images from the local registry, as they will be absent from the nodes. From sz_cuitao at 163.com Tue Aug 31 01:14:19 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Tue, 31 Aug 2021 09:14:19 +0800 Subject: How to stop the whole system gracefully ? In-Reply-To: <00af01d79d61$1adb57d0$50920770$@163.com> References: <00af01d79d61$1adb57d0$50920770$@163.com> Message-ID: <010b01d79e05$8719a970$954cfc50$@163.com> Anyone can help me ? From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org On Behalf Of Tommy Sway Sent: Monday, August 30, 2021 1:37 PM To: 'openstack-discuss' Subject: How to stop the whole system gracefully ? My system is installed using kola-ansible. The database was inconsistent due to the last unexpected shutdown, and the system could not start normally, which was very troublesome. I would like to ask what command should be used to shut down the entire system gracefully in an emergency ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingjisun at vmware.com Tue Aug 31 01:17:06 2021 From: yingjisun at vmware.com (Yingji Sun) Date: Tue, 31 Aug 2021 01:17:06 +0000 Subject: A question about nova live-migration across AZ Message-ID: Buddies, I can migration nova instance across available zones with the command below. Suppose instance is in AZ1 and host is in AZ2. nova --os-compute-api-version 2.67 live-migration --force [--block-migrate] [] After migration, the instance’s available zone is changed to AZ2. However, the available zone information in request_specs was not changed. So next time when trying to migrate the instance without specifying a target, the migration target will be selected through nova scheduler, by the availability zone value (AZ1) saved in request_specs. This caused some error. Is this an expected behavior ? Yingji. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Tue Aug 31 02:52:14 2021 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Mon, 30 Aug 2021 22:52:14 -0400 Subject: A question about nova live-migration across AZ In-Reply-To: References: Message-ID: It seems to be the expected behavior from the AZ doc. https://docs.openstack.org/nova/latest/admin/availability-zones.html Knowing this, it is dangerous to force a server to another host with evacuate or live migrate if the server is restricted to a zone and is then forced to move to a host in another zone, because that will create an inconsistency in the internal tracking of where that server should live and may require manually updating the database for that server. For example, if a user creates a server in zone A and then the admin force live migrates the server to zone B, and then the user resizes the server, the scheduler will try to move it back to zone A which may or may not work, e.g. if the admin deleted or renamed zone A in the interim. On Mon, Aug 30, 2021 at 9:18 PM Yingji Sun wrote: > Buddies, > > > > I can migration nova instance across available zones with the command > below. Suppose instance is in AZ1 and host is in AZ2. > > > > nova --os-compute-api-version 2.67 live-migration --force > [--block-migrate] [] > > > > After migration, the instance’s available zone is changed to AZ2. > > > > However, the available zone information in request_specs was not changed. > > > > So next time when trying to migrate the instance without specifying a > target, the migration target will be selected through nova scheduler, by > the availability zone value (AZ1) saved in request_specs. This caused some > error. > > > > Is this an expected behavior ? > > > > Yingji. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Tue Aug 31 04:11:37 2021 From: gagehugo at gmail.com (Gage Hugo) Date: Mon, 30 Aug 2021 23:11:37 -0500 Subject: No meeting tomorrow Message-ID: Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be Sept 7th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Tue Aug 31 05:18:29 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 31 Aug 2021 07:18:29 +0200 Subject: [Kolla] update In-Reply-To: References: Message-ID: Thanks, now it is clear for me. Ignazio Il Mar 31 Ago 2021, 00:03 Pierre Riteau ha scritto: > On Mon, 30 Aug 2021 at 17:48, Ignazio Cassano > wrote: > > > > Hello, I would like to ask if the procedure I am using for update my > kolla wallaby is correct. > > Every week new images are released so I execute the following steps: > > > > 1. Pull new images on my local registry > > > > 2 pull new images from my local registry to controllers and compute nodes > > > > 3 kolla-ansible deploy > > > > Are the above steps the correct way or I missed something? > > Must I clean something before deploying ? > > Thanks > > > > Ignazio > > This approach is correct. Step 2 will ensure `kolla-ansible deploy` > knows that new images are available. You can verify it yourself: after > executing step 2, run `docker ps` on your nodes and you should see > containers running from images identified only by an ID. This is > because the tag (for example wallaby) references the new image. > > However, as Sean said, changing the tag each time you redeploy will > allow you to revert to previous container images if anything went bad. > Additionally, it would allow you to skip step 2, since the deploy > command will automatically pull images from the local registry, as > they will be absent from the nodes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arne.wiebalck at cern.ch Tue Aug 31 06:01:30 2021 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Tue, 31 Aug 2021 08:01:30 +0200 Subject: [baremetal-sig][ironic] Tue Sep 7, 2021, 2pm UTC: Ironic User & Operator Feedback Message-ID: Dear all, The Bare Metal SIG is back from the summer break and will zoom-meet next week, Tue Sep 7, 2021, at 2pm UTC. To start the new season, this first session will focus on: User/operator/admin feedback for Ironic So come along, meet other Ironicers and discuss your Ironic pain points, issues, experiences and ideas with the community and in particular the upstream developers! Everyone, in particular not-yet Ironicers, are welcome to join! All details can be found on: https://etherpad.opendev.org/p/bare-metal-sig Hope to see you there! Arne (for the Bare Metal SIG) From lyarwood at redhat.com Tue Aug 31 09:21:15 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Tue, 31 Aug 2021 10:21:15 +0100 Subject: A question about nova live-migration across AZ In-Reply-To: References: Message-ID: <20210831092115.7anjf4gikrxbzhe3@lyarwood-laptop.usersys.redhat.com> On 30-08-21 22:52:14, Laurent Dumont wrote: > It seems to be the expected behavior from the AZ doc. > > https://docs.openstack.org/nova/latest/admin/availability-zones.html > > Knowing this, it is dangerous to force a server to another host with > evacuate or live migrate if the server is restricted to a zone and is then > forced to move to a host in another zone, because that will create an > inconsistency in the internal tracking of where that server should live and > may require manually updating the database for that server. For example, if > a user creates a server in zone A and then the admin force live migrates > the server to zone B, and then the user resizes the server, the scheduler > will try to move it back to zone A which may or may not work, e.g. if the > admin deleted or renamed zone A in the interim. As listed in that doc the better approach is to shelve and then unshelve into the specific target AZ. This should update the request spec avoiding the post move issues described above. https://docs.openstack.org/api-ref/compute/?expanded=unshelve-restore-shelved-server-unshelve-action-detail#unshelve-restore-shelved-server-unshelve-action > On Mon, Aug 30, 2021 at 9:18 PM Yingji Sun wrote: > > > Buddies, > > > > > > > > I can migration nova instance across available zones with the command > > below. Suppose instance is in AZ1 and host is in AZ2. > > > > > > > > nova --os-compute-api-version 2.67 live-migration --force > > [--block-migrate] [] > > > > > > > > After migration, the instance’s available zone is changed to AZ2. > > > > > > > > However, the available zone information in request_specs was not changed. > > > > > > > > So next time when trying to migrate the instance without specifying a > > target, the migration target will be selected through nova scheduler, by > > the availability zone value (AZ1) saved in request_specs. This caused some > > error. > > > > > > > > Is this an expected behavior ? > > > > > > > > Yingji. > > -- 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 31 10:02:32 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 31 Aug 2021 11:02:32 +0100 Subject: A question about nova live-migration across AZ In-Reply-To: References: Message-ID: <4e3f8057319471f8891bb2e421a36e770302e81b.camel@redhat.com> On Mon, 2021-08-30 at 22:52 -0400, Laurent Dumont wrote: > It seems to be the expected behavior from the AZ doc. > > https://docs.openstack.org/nova/latest/admin/availability-zones.html > > Knowing this, it is dangerous to force a server to another host with > evacuate or live migrate if the server is restricted to a zone and is then > forced to move to a host in another zone, because that will create an > inconsistency in the internal tracking of where that server should live and > may require manually updating the database for that server. For example, if > a user creates a server in zone A and then the admin force live migrates > the server to zone B, and then the user resizes the server, the scheduler > will try to move it back to zone A which may or may not work, e.g. if the > admin deleted or renamed zone A in the interim. yes AZ are not really something that shoudl chage over the lifetime of an instance. in nova we cannot assume connectivnty between hosts in different AZ at teh hyperviors level. e.g. we cannot assume that libvirt runing on the host can comunicate directly. as a result we do not support live migrateion or cold migration between AZs. glance however can be assumed to be abvaiable across AZ so we do allow unshleve to unshleve to a different AZ. that is really the only way that we support moving instance between azs. > > > On Mon, Aug 30, 2021 at 9:18 PM Yingji Sun wrote: > > > Buddies, > > > > > > > > I can migration nova instance across available zones with the command > > below. Suppose instance is in AZ1 and host is in AZ2. > > > > > > > > nova --os-compute-api-version 2.67 live-migration --force > > [--block-migrate] [] > > > > > > > > After migration, the instance’s available zone is changed to AZ2. > > > > > > > > However, the available zone information in request_specs was not changed. > > > > > > > > So next time when trying to migrate the instance without specifying a > > target, the migration target will be selected through nova scheduler, by > > the availability zone value (AZ1) saved in request_specs. This caused some > > error. > > > > > > > > Is this an expected behavior ? > > > > > > > > Yingji. > > From smooney at redhat.com Tue Aug 31 10:07:55 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 31 Aug 2021 11:07:55 +0100 Subject: How to stop the whole system gracefully ? In-Reply-To: <010b01d79e05$8719a970$954cfc50$@163.com> References: <00af01d79d61$1adb57d0$50920770$@163.com> <010b01d79e05$8719a970$954cfc50$@163.com> Message-ID: On Tue, 2021-08-31 at 09:14 +0800, Tommy Sway wrote: > Anyone can help me ? > > > i belive what you are lookign for is "kolla-ansibel stop" then after the issue is resolved you can do kolla-ansible mariadb_recovery  then  kolla-ansible deploy-containers https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#kolla-ansible-cli > > > > > > > From: openstack-discuss-bounces+sz_cuitao=163.com at lists.openstack.org > On Behalf > Of Tommy Sway > Sent: Monday, August 30, 2021 1:37 PM > To: 'openstack-discuss' > Subject: How to stop the whole system gracefully ? > > > > My system is installed using kola-ansible. > > The database was inconsistent due to the last unexpected shutdown, and the > system could not start normally, which was very troublesome. > > I would like to ask what command should be used to shut down the entire > system gracefully in an emergency ? > > > > Thanks. > > > > > From tonykarera at gmail.com Tue Aug 31 11:53:54 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 31 Aug 2021 13:53:54 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello Guys, I was able to configure the cluster internal network with Vlans. The communication was ok but I still get the same error + sleep 5 ++ kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? + '[' ok = '' ']' Regards Tony Karera On Sat, Aug 28, 2021 at 4:43 AM Mohammed Naser wrote: > AFAIK, Magnum does not control what encapsulation type is being used. > > Is there a chance you have “vlan” inside tenant_network_types ? > > On Tue, Aug 24, 2021 at 12:05 AM Karera Tony wrote: > >> Hello Team, >> >> I was able to deploy Openstack with Magnum and Zun enabled. >> >> Unfortunately, When I create a cluster, Heat configure the fix/_network >> for the nodes with Vlan and the nodes fail to get IPs. >> >> I was wondering if it is possible to trick the heat templates to create >> vxlan network instead of vlan. >> >> Regards >> >> Tony Karera >> >> >> -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Tue Aug 31 13:41:03 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 31 Aug 2021 15:41:03 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Dear Ammad, Sorry to bother you again but I have failed to get the right command to use to check. Every Kubectl command I run on either the master or worker. The connection to the server localhost:8080 was refused - did you specify the right host or port? I get the error below. Regards Tony Karera On Fri, Aug 27, 2021 at 9:15 AM Ammad Syed wrote: > Your hyperkube services are not started. > > You need to check hyperkube services. > > Ammad > > On Fri, Aug 27, 2021 at 10:35 AM Karera Tony wrote: > >> Dear Ammad, >> >> Below is the output of podman ps >> >> CONTAINER ID IMAGE >> COMMAND CREATED STATUS PORTS NAMES >> 319fbebc2f50 >> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 >> /usr/bin/start-he... 23 hours ago Up 23 hours ago >> heat-container-agent >> [root at k8s-cluster-2-4faiphvzsmzu-master-0 core]# >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Thu, Aug 26, 2021 at 9:54 AM Ammad Syed wrote: >> >>> The output in >>> logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd >>> is incomplete. >>> >>> There should be the installation and configuration of many other things >>> that are missing. Also it looks that hyperkube is not installed. >>> >>> Can you check the response of "podman ps" command on master nodes. >>> >>> Ammad >>> >>> On Thu, Aug 26, 2021 at 11:30 AM Karera Tony >>> wrote: >>> >>>> Here is the beginning of the Log >>>> >>>> Starting to run kube-apiserver-to-kubelet-role >>>> + echo 'Waiting for Kubernetes API...' >>>> Waiting for Kubernetes API... >>>> ++ kubectl get --raw=/healthz >>>> The connection to the server localhost:8080 was refused - did you >>>> specify the right host or port? >>>> + '[' ok = '' ']' >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar >>>> wrote: >>>> >>>>> I assume these are from the master nodes? Can you share the logs >>>>> shortly after creation rather than when it times out? I think there is some >>>>> missing logs from the top. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 26 Aug 2021, at 06:14, Karera Tony wrote: >>>>> >>>>>  >>>>> Hello Guys, >>>>> >>>>> Attached are the two logs from the >>>>> /var/log/heat-config/heat-config-script directory >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony >>>>> wrote: >>>>> >>>>>> Dear Sir, >>>>>> >>>>>> You are right. >>>>>> >>>>>> I am getting this error >>>>>> >>>>>> kubectl get --raw=/healthz >>>>>> The connection to the server localhost:8080 was refused - did you >>>>>> specify the right host or port? >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >>>>>> wrote: >>>>>> >>>>>>> I’d check the logs under /var/log/heat-config. >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>>>>> >>>>>>>  >>>>>>> DeaR Ammad, >>>>>>> >>>>>>> I was able to make the communication work and the Worker nodes were >>>>>>> created as well but the cluster failed. >>>>>>> >>>>>>> I logged in to the master node and there was no error but below are >>>>>>> the error when I run systemctl status heat-container-agent on the worker >>>>>>> noed. >>>>>>> >>>>>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>>>>>> wrote: >>>>>>> >>>>>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>>>>>> reachable from master and worker nodes. >>>>>>>> >>>>>>>> You can use below guide for the reference as well. >>>>>>>> >>>>>>>> >>>>>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>>>>> >>>>>>>> Ammad >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello Ammad, >>>>>>>>> >>>>>>>>> I have deployed using the given image but I think there is an >>>>>>>>> issue with keystone as per the screen shot below when I checked the master >>>>>>>>> node's heat-container-agent status >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Tony Karera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello Ammad, >>>>>>>>>> >>>>>>>>>> I actually first used that one and it was also getting stuck. >>>>>>>>>> >>>>>>>>>> I will try this one again and update you with the Logs though. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Tony Karera >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> It seems from the logs that you are using fedora atomic. Can you >>>>>>>>>>> try with FCOS 32 image. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>>>>> >>>>>>>>>>> Ammad >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony < >>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Sir, >>>>>>>>>>>> >>>>>>>>>>>> Attached is the Log file >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Tony Karera >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed < >>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Karera, >>>>>>>>>>>>> >>>>>>>>>>>>> Can you share us the full log file. >>>>>>>>>>>>> >>>>>>>>>>>>> Ammad >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony < >>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Guys, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>>>>>> keeps appearing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Karera >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>>>>>> status. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Ammad >>>>>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> There is no directory or log relevant to heat in the >>>>>>>>>>>>>>> /var/log directory >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Regards >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Login to master node and check the logs of heat agent in >>>>>>>>>>>>>>> var log. There must be something the cluster is stucking somewhere in >>>>>>>>>>>>>>> creating. >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Ammad >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain >>>>>>>>>>>>>>> point. The master node was created but the cluster remained in Creation in >>>>>>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>>>>> >>>> default-master >>>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Regards >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> You can try by creating your private vxlan network >>>>>>>>>>>>>>> prior to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I >>>>>>>>>>>>>>> deploy it, It creates a fixed network using vlan which I am not using for >>>>>>>>>>>>>>> internal networks. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the >>>>>>>>>>>>>>> cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster create >>>>>>>>>>>>>>> command look like? >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> -- >>>>>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> -- >>>>>>>>>>>>>>> >>> Regards, >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > -- >>>>>>>>>>>>>>> > Regards, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> >>>>>>>> Syed Ammad Ali >>>>>>>> >>>>>>> >>>>> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >>>>> >>>>> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> >>>>> >>>>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pshchelokovskyy at mirantis.com Tue Aug 31 13:46:53 2021 From: pshchelokovskyy at mirantis.com (Pavlo Shchelokovskyy) Date: Tue, 31 Aug 2021 16:46:53 +0300 Subject: [nova][cinder][barbican] storing secrets in service project Message-ID: Hi all, When Barbican is involved, and services like Nova and Cinder create secrets behind the scenes themselves, this results in problems deleting or otherwise managing some resources by cloud admins. For example as described in https://bugs.launchpad.net/cinder/+bug/1775372, admin can not delete an encrypted volume created by another user, and needs to resort to adding herself to the project first with appropriate roles. This stems IMO from the difference in default resource access policies between Barbican and other services that consume it. For example, while in Nova or Cinder, cloud admin by default can delete servers or volumes in other projects, in Barbican by default only secret creator or admin "in the same project" can delete a secret. I came up with at least 3 solutions (already mentioned in the issue above) but would like to discuss their validity, pros and cons, and especially how they affect the security model and the use cases that this Nova-Cinder-Barbican integration aims to solve. 1. Just ignore failure to delete a secret and log appropriate warning that a secret may be left orphaned. Obviously not the best solution, but rather simple one, also will protect from cases when for whatever reason a secret will be deleted from Barbican directly (e.g. by mistake), rendering volume undeletable for anyone. 2. Change default barbican policies to allow secret deletion for cloud admin (system scope?). Naturally has implications for the Barbican model for resources access, so may be not that appropriate. 3. Store the secrets in the service project instead of user's. Currently those secrets are generated by Nova or Cinder themselves, and user quite probably is not even aware that there was something created in Barbican on her behalf. The user also has no option to pass her own secrets to any of the involved API calls, so this is something happening completely behind the scenes. So do we really need to store these secrets in the user's project? Wouldn't it be better to store them in the service project, have the same service user defined in Nova and Cinder, so it can operate and access those secrets regardless of who manages the resource which depends on access to this secret? This also may solve the problem of encrypted local instance images in Nova, where upon host restart, Nova is not able to bring those instances up because it lacks the context capable of accessing those secrets. I think the third option is the best one, but I may be missing the actual use case meant behind this feature. Is it "keep the data encrypted at rest and in transit" or more strictly "encrypt data of different users with different keys and limit access to those keys" (for the case of breach etc) ? In the first case it seems storing all the auto-generated secrets in a service project would suffice... Please help me understand the best approach to take. Best regards, Pavlo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Aug 31 14:14:21 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 31 Aug 2021 16:14:21 +0200 Subject: [nova][placement] Asia friendly meeting slot on 2nd of Sept Message-ID: Hi, This is a reminder that the next Asia friendly Nova meeting timeslot is coming up this week on Thursday 8:00 UTC[1]. We will hold that meeting on IRC[2] in the #openstack-nova channel on the OFTC server. See you there. Cheers, gibi [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-09-02T08:00:00 [2] https://docs.openstack.org/contributors/common/irc.html From smooney at redhat.com Tue Aug 31 14:17:09 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 31 Aug 2021 15:17:09 +0100 Subject: [nova][cinder][barbican] storing secrets in service project In-Reply-To: References: Message-ID: <8ef51d37977fb2cd2d37fa6ccc69fa7864032598.camel@redhat.com> On Tue, 2021-08-31 at 16:46 +0300, Pavlo Shchelokovskyy wrote: > Hi all, > > When Barbican is involved, and services like Nova and Cinder create secrets > behind the scenes themselves, > this results in problems deleting or otherwise managing some resources by > cloud admins. this is mostly by design. cloud admin shoudl not be able to access tenat secret or teants cannot trust the cloud. > > For example as described in https://bugs.launchpad.net/cinder/+bug/1775372, > admin can not delete an encrypted volume created by another user, > and needs to resort to adding herself to the project first with appropriate > roles. yep although i woudl argue that unless that is an abuse of admin privialges. there are some case where the admin woudl have to intervient like this but its generally agaisnt the self service model for admin to be doing this. > > This stems IMO from the difference in default resource access policies > between Barbican and other services that consume it. > For example, while in Nova or Cinder, cloud admin by default can delete > servers or volumes in other projects, > in Barbican by default only secret creator or admin "in the same project" > can delete a secret. > > I came up with at least 3 solutions (already mentioned in the issue above) > but would like > to discuss their validity, pros and cons, and especially how they affect > the security model > and the use cases that this Nova-Cinder-Barbican integration aims to solve. > > 1. Just ignore failure to delete a secret and log appropriate warning that > a secret may be left orphaned. > Obviously not the best solution, but rather simple one, also will protect > from cases when for whatever reason > a secret will be deleted from Barbican directly (e.g. by mistake), > rendering volume undeletable for anyone. > > 2. Change default barbican policies to allow secret deletion for cloud > admin (system scope?). > Naturally has implications for the Barbican model for resources access, so > may be not that appropriate. > > 3. Store the secrets in the service project instead of user's. > Currently those secrets are generated by Nova or Cinder themselves, and > user quite probably is not even aware > that there was something created in Barbican on her behalf. The user also > has no option to pass her own secrets > to any of the involved API calls, so this is something happening completely > behind the scenes. > So do we really need to store these secrets in the user's project? > Wouldn't it be better to store them in the service project, have the same > service user defined in Nova and Cinder, > so it can operate and access those secrets regardless of who manages the > resource which depends on access to this secret? > This also may solve the problem of encrypted local instance images in Nova, > where upon host restart, > Nova is not able to bring those instances up because it lacks the context > capable of accessing those secrets. > > I think the third option is the best one, but I may be missing the actual > use case meant behind this feature. i am not sure i agree. we intentionally do not allow admin to start instance that have encypted storage as the admin should not be able to access the decrypted data. yes they could always hack around this but to me this is intentioaly not supported and not a bug. > Is it "keep the data encrypted at rest and in transit" or more strictly > "encrypt data of different users with different keys > and limit access to those keys" (for the case of breach etc) ? > In the first case it seems storing all the auto-generated secrets in a > service project would suffice... its both the intent is to keep the data encyprted at rest and in transit and ensur that admin cannot decypt it. deletetion of hte resouce is perhaps somethign that could be allowable with a sytem admin token retrivial of the secreate e.g. to start the vm or do a snapthot for exmaple i think would be a regression in security and not something we shoudl do. and yes im aware that admin can already change default plicy in barbican to allow them to retirve the securet or add themsevles to the project to circumvent some of the protections. i dont think its in scope of nova ot manage any user secreate or user data in general. moving this into the proejct like nova and cinder changes the security model and risk assment for operators and devleopers of thoes services. we woudl be adding user data that need to be managed in a way that is complient with strict standard where as by using barbican we can cerntrailse that to a singel service which has one role, manage secrets. > > Please help me understand the best approach to take. > > Best regards, > Pavlo. From iurygregory at gmail.com Tue Aug 31 14:24:42 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Tue, 31 Aug 2021 16:24:42 +0200 Subject: [release][heat][ironic][requirements][swift][OpenStackSDK][vitrage][barbican][heat][horizon][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: References: Message-ID: Thanks Herve, I will take a look at the ironic deliverables. Em seg., 30 de ago. de 2021 às 16:24, Herve Beraud escreveu: > Hello teams > > Quick reminder that we'll need a release very soon for a number of > deliverables following a cycle-with-intermediary release model but which > have not done *any* release yet in the Xena cycle: > > ansible-role-atos-hsm > ansible-role-lunasa-hsm > ansible-role-thales-hsm > heat-agents > horizon > ironic-prometheus-exporter > ironic-python-agent-builder > ironic-ui > ovn-octavia-provider > patrole > python-openstackclient > requirements > swift > tempest > vitrage-dashboard > vitrage > > > Those should be released ASAP, and in all cases before the week of 13 September, 2021, so > that we have a release to include in the final Xena release. > > Thanks for your attention. > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > > -- *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 ildiko.vancsa at gmail.com Tue Aug 31 14:31:12 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 31 Aug 2021 07:31:12 -0700 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: References: Message-ID: Hi, As we are approaching the end of the holiday season I wanted to surface back my question about GPU performance testing. Does anyone have any hints to find the best tools to do some benchmarking with? Thanks, Ildikó > On Aug 9, 2021, at 08:46, Ildiko Vancsa wrote: > > 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 ionut at fleio.com Tue Aug 31 14:28:17 2021 From: ionut at fleio.com (Ionut Biru) Date: Tue, 31 Aug 2021 17:28:17 +0300 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: What version of fedora coreos are you using? On Tue, Aug 31, 2021 at 4:52 PM Karera Tony wrote: > Dear Ammad, > > Sorry to bother you again but I have failed to get the right command to > use to check. > > Every Kubectl command I run on either the master or worker. > The connection to the server localhost:8080 was refused - did you specify > the right host or port? > I get the error below. > > > Regards > > Tony Karera > > > > > On Fri, Aug 27, 2021 at 9:15 AM Ammad Syed wrote: > >> Your hyperkube services are not started. >> >> You need to check hyperkube services. >> >> Ammad >> >> On Fri, Aug 27, 2021 at 10:35 AM Karera Tony >> wrote: >> >>> Dear Ammad, >>> >>> Below is the output of podman ps >>> >>> CONTAINER ID IMAGE >>> COMMAND CREATED STATUS PORTS >>> NAMES >>> 319fbebc2f50 >>> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 >>> /usr/bin/start-he... 23 hours ago Up 23 hours ago >>> heat-container-agent >>> [root at k8s-cluster-2-4faiphvzsmzu-master-0 core]# >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Thu, Aug 26, 2021 at 9:54 AM Ammad Syed >>> wrote: >>> >>>> The output in >>>> logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd >>>> is incomplete. >>>> >>>> There should be the installation and configuration of many other things >>>> that are missing. Also it looks that hyperkube is not installed. >>>> >>>> Can you check the response of "podman ps" command on master nodes. >>>> >>>> Ammad >>>> >>>> On Thu, Aug 26, 2021 at 11:30 AM Karera Tony >>>> wrote: >>>> >>>>> Here is the beginning of the Log >>>>> >>>>> Starting to run kube-apiserver-to-kubelet-role >>>>> + echo 'Waiting for Kubernetes API...' >>>>> Waiting for Kubernetes API... >>>>> ++ kubectl get --raw=/healthz >>>>> The connection to the server localhost:8080 was refused - did you >>>>> specify the right host or port? >>>>> + '[' ok = '' ']' >>>>> >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar >>>>> wrote: >>>>> >>>>>> I assume these are from the master nodes? Can you share the logs >>>>>> shortly after creation rather than when it times out? I think there is some >>>>>> missing logs from the top. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On 26 Aug 2021, at 06:14, Karera Tony wrote: >>>>>> >>>>>>  >>>>>> Hello Guys, >>>>>> >>>>>> Attached are the two logs from the >>>>>> /var/log/heat-config/heat-config-script directory >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony >>>>>> wrote: >>>>>> >>>>>>> Dear Sir, >>>>>>> >>>>>>> You are right. >>>>>>> >>>>>>> I am getting this error >>>>>>> >>>>>>> kubectl get --raw=/healthz >>>>>>> The connection to the server localhost:8080 was refused - did you >>>>>>> specify the right host or port? >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Tony Karera >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 25, 2021 at 10:55 PM Bharat Kunwar >>>>>>> wrote: >>>>>>> >>>>>>>> I’d check the logs under /var/log/heat-config. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On 25 Aug 2021, at 19:39, Karera Tony wrote: >>>>>>>> >>>>>>>>  >>>>>>>> DeaR Ammad, >>>>>>>> >>>>>>>> I was able to make the communication work and the Worker nodes were >>>>>>>> created as well but the cluster failed. >>>>>>>> >>>>>>>> I logged in to the master node and there was no error but below are >>>>>>>> the error when I run systemctl status heat-container-agent on the worker >>>>>>>> noed. >>>>>>>> >>>>>>>> Aug 25 17:52:24 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:52:55 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:53:26 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:53:57 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:54:28 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:54:59 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:55:29 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:56:00 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:56:31 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Aug 25 17:57:02 cluster1-fmkpva3nozf7-node-0 podman[2268]: >>>>>>>> /var/lib/os-collect-config/local-data not found. Skipping >>>>>>>> Regards >>>>>>>> >>>>>>>> Tony Karera >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 25, 2021 at 10:38 AM Ammad Syed >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Yes, keystone, Heat, Barbicane and magnum public endpoints must be >>>>>>>>> reachable from master and worker nodes. >>>>>>>>> >>>>>>>>> You can use below guide for the reference as well. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>>>>>>>> >>>>>>>>> Ammad >>>>>>>>> >>>>>>>>> On Wed, Aug 25, 2021 at 12:08 PM Karera Tony >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello Ammad, >>>>>>>>>> >>>>>>>>>> I have deployed using the given image but I think there is an >>>>>>>>>> issue with keystone as per the screen shot below when I checked the master >>>>>>>>>> node's heat-container-agent status >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Tony Karera >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 25, 2021 at 8:28 AM Karera Tony >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hello Ammad, >>>>>>>>>>> >>>>>>>>>>> I actually first used that one and it was also getting stuck. >>>>>>>>>>> >>>>>>>>>>> I will try this one again and update you with the Logs though. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Tony Karera >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 25, 2021 at 8:25 AM Ammad Syed < >>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> It seems from the logs that you are using fedora atomic. Can >>>>>>>>>>>> you try with FCOS 32 image. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>>>>>>>>>>> >>>>>>>>>>>> Ammad >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 25, 2021 at 11:20 AM Karera Tony < >>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello Sir, >>>>>>>>>>>>> >>>>>>>>>>>>> Attached is the Log file >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Karera >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 25, 2021 at 7:31 AM Ammad Syed < >>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Karera, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you share us the full log file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ammad >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Aug 25, 2021 at 9:42 AM Karera Tony < >>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Guys, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks a lot for the help but unfortunately I dont see much >>>>>>>>>>>>>>> information in the log file indicating a failure apart from the log that >>>>>>>>>>>>>>> keeps appearing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tony Karera >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Aug 24, 2021 at 8:12 PM Mohammed Naser < >>>>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also check out /var/log/cloud-init.log :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Aug 24, 2021 at 1:39 PM Ammad Syed < >>>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Then check journalctl -xe or status of heat agent service >>>>>>>>>>>>>>>> status. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Ammad >>>>>>>>>>>>>>>> > On Tue, Aug 24, 2021 at 10:36 PM Karera Tony < >>>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Hello Ammad, >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> There is no directory or log relevant to heat in the >>>>>>>>>>>>>>>> /var/log directory >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Regards >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Tony Karera >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> On Tue, Aug 24, 2021 at 12:43 PM Ammad Syed < >>>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Hi Karera, >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Login to master node and check the logs of heat agent >>>>>>>>>>>>>>>> in var log. There must be something the cluster is stucking somewhere in >>>>>>>>>>>>>>>> creating. >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Ammad >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> On Tue, Aug 24, 2021 at 3:41 PM Karera Tony < >>>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Hello Ammad, >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> I had done as explained and it worked upto a certain >>>>>>>>>>>>>>>> point. The master node was created but the cluster remained in Creation in >>>>>>>>>>>>>>>> progress for over an hour and failed with error below >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Stack Faults >>>>>>>>>>>>>>>> >>>> as follows: >>>>>>>>>>>>>>>> >>>> default-master >>>>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>>>> >>>> default-worker >>>>>>>>>>>>>>>> >>>> Timed out >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Regards >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Tony Karera >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> On Tue, Aug 24, 2021 at 9:25 AM Ammad Syed < >>>>>>>>>>>>>>>> syedammad83 at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Hi Tony, >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> You can try by creating your private vxlan network >>>>>>>>>>>>>>>> prior to deployment of cluster and explicitly create your cluster in vxlan >>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> --fixed-network private --fixed-subnet private-subnet >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> You can specify above while creating a cluster. >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Ammad >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> On Tue, Aug 24, 2021 at 11:59 AM Karera Tony < >>>>>>>>>>>>>>>> tonykarera at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> Hello MOhamed, >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> I think the Kubernetes cluster is ok but it when I >>>>>>>>>>>>>>>> deploy it, It creates a fixed network using vlan which I am not using for >>>>>>>>>>>>>>>> internal networks. >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> When I create a a vxlan Network and use it in the >>>>>>>>>>>>>>>> cluster creation, It fails. Is there a trick around this ? >>>>>>>>>>>>>>>> >>>>>> Regards >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> Tony Karera >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> On Fri, Aug 20, 2021 at 9:00 AM feilong < >>>>>>>>>>>>>>>> feilong at catalyst.net.nz> wrote: >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>> 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 < >>>>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>>>> mnaser at vexxhost.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> What does your cluster template and cluster >>>>>>>>>>>>>>>> create command look like? >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony < >>>>>>>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>>>>>> feilong at catalyst.net.nz> 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. >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> -- >>>>>>>>>>>>>>>> >>>>> Regards, >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Syed Ammad Ali >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> -- >>>>>>>>>>>>>>>> >>> Regards, >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Syed Ammad Ali >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > -- >>>>>>>>>>>>>>>> > Regards, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Syed Ammad Ali >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Mohammed Naser >>>>>>>>>>>>>>>> VEXXHOST, Inc. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Syed Ammad Ali >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Syed Ammad Ali >>>>>>>>> >>>>>>>> >>>>>> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >>>>>> >>>>>> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> >>>>>> >>>>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> Syed Ammad Ali >>>> >>> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue Aug 31 14:39:01 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 31 Aug 2021 07:39:01 -0700 Subject: [zun][cyborg][kuryr] Re: Edge for scientific research session on September 13 Edge WG meeting In-Reply-To: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> References: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> Message-ID: Hi, It is a friendly reminder that the OpenInfra Edge Computing Group is having a joint session with the Chameleon project. During this session you can learn about the Chameleon project and how they are using OpenStack to build an edge platform for scientific research and academic purposes. They have also found some gaps during their journey. To mention an example the integration between Cyborg and Zun is missing to be able to use acceleration devices with containers orchestrated by OpenStack and they have been working to fill in this gap. The session will start with a presentation about the project and then we will use the remaining time to talk about solutions and next steps. I would like to invite everyone who is interested in learning about how OpenStack can be turned into an edge platform and what are the missing pieces of the puzzle that still need to be enhanced or implemented. The session will take place on the OpenInfra Edge Computing Group weekly call on __September 13, at 1300 UTC / 6am Pacific__. The meeting will be held on Zoom, for the latest dial-in information please refer to this page: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Please let me know if you need a calendar invite and I can send you one to get reminded about the meeting. Thanks and Best Regards, Ildikó > On Aug 25, 2021, at 17:00, Ildiko Vancsa wrote: > > Hi, > > I’m very excited to invite you to a session with the Chameleon project to discuss how edge computing is powering education, scientific research and more! As always in the area of edge there are challenges and gaps that we need to solve together. In that sense the session will start with a presentation that we will then turn into a discussion to turn towards discussing solutions. > > Please also note that the Chameleon project is using OpenStack to build edge solutions. As they identified some gaps they would like to work with the community to address the challenges that they’ve been hitting. Please join us to get their feedback and find the best way to improve OpenStack to deliver a platform that can be used on the edge! > > The session will take place on the OpenInfra Edge Computing Group weekly call on __September 13, at 1300 UTC / 6am Pacific__. > For the latest dial-in information please refer to this page: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings > > Please find the details of the session below. > > Thanks and Best Regards, > Ildikó > > > Title: Chameleon: a cloud to edge infrastructure for science > > Abstract: The NSF-funded Chameleon project (www.chameleoncloud.org) provides an OpenStack-based bare metal reconfigurable cloud that supports systems research, education, and emergent application projects in science. The facility has been in existence for 6+ years, and has served ~6,000 users working on a variety of projects ranging from networking, operating systems design, and security, to innovative applications in astronomy, physics, and life sciences. Recent research trends in IoT and edge computing, as evidenced by increased numbers of project applications in those areas, made it clear that Chameleon needed to expand into the edge space. Remaining within the OpenStack framework allowed us to leverage end-user features that we developed for Chameleon, such as access via federated identity and Jupyter integration. Accordingly, we developed infrastructure called CHI at Edge that adapts Zun to provision containers on edge devices and significantly expands its capabilities to work in the edge space. The talk will describe our use case and the emergent product definition, the OpenStack adaptations we made to the current preview implementation, the directions we plan to take in our further work, as well as the ecosystem of projects and NSF infrastructure deployments leveraging this work and collaborating with us. > > From arthur.outhenin-chalandre at cern.ch Tue Aug 31 14:50:57 2021 From: arthur.outhenin-chalandre at cern.ch (Arthur Outhenin-Chalandre) Date: Tue, 31 Aug 2021 16:50:57 +0200 Subject: [cinder][nova] fsfreeze hooks issues with cinder snapshot/backup Message-ID: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> Hello, We are trying to trigger an fsfreeze via a cinder backup or snapshot. We confirmed that the fsfreeze hooks are actually called with a nova snapshot with `/var/log/qga-fsfreeze-hook.log` in the VM, but we can't achieve the same thing with a cinder backup/snapshot attached to the same instance. We are using Wallaby, libvirt, RBD for cinder volumes and RBD as well for cinder-backup. According to this (old) spec [0], cinder should call the `quiesce()` method in nova during backup/snapshot. We looked in the cinder code and couldn't find any clear evidence that this method is actually called by cinder (but we may have missed something). We added some debug messages on quiesce/can_quiesce/require_quiesce/... in `nova/virt/libvirt/driver.py` and they are never called with a cinder backup/snapshot in our setup while they are (and succeed) if we do a nova snapshot. We are starting to suspect that something is missing in cinder, but it could very well be a problem with our setup as well... Does someone use this feature or know if it should be working/implemented? [0]: https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent#Cinder Cheers, -- Arthur Outhenin-Chalandre From fungi at yuggoth.org Tue Aug 31 15:00:24 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 31 Aug 2021 15:00:24 +0000 Subject: [OSSA-2021-005] Neutron: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts (CVE-2021-40085) Message-ID: <20210831150024.hf4wokbh2umhqwud@yuggoth.org> ==================================================================== OSSA-2021-005: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts ==================================================================== :Date: August 31, 2021 :CVE: CVE-2021-40085 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~~~~~~~~~ Pavel Toporkov reported a vulnerability in Neutron. By supplying a specially crafted extra_dhcp_opts value, an authenticated user may add arbitrary configuration to the dnsmasq process in order to crash the service, change parameters for other tenants sharing the same interface, or otherwise alter that daemon's behavior. This vulnerability may also be used to trigger a configuration parsing buffer overflow in versions of dnsmasq prior to 2.81, which could lead to remote code execution. All Neutron deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/806750 (Ussuri) - https://review.opendev.org/806749 (Victoria) - https://review.opendev.org/806748 (Wallaby) - https://review.opendev.org/806746 (Xena) Credits ~~~~~~~ - Pavel Toporkov (CVE-2021-40085) References ~~~~~~~~~~ - https://launchpad.net/bugs/1939733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40085 -- 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 sbauza at redhat.com Tue Aug 31 15:10:03 2021 From: sbauza at redhat.com (Sylvain Bauza) Date: Tue, 31 Aug 2021 17:10:03 +0200 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: References: Message-ID: On Tue, Aug 31, 2021 at 4:34 PM Ildiko Vancsa wrote: > Hi, > > As we are approaching the end of the holiday season I wanted to surface > back my question about GPU performance testing. Does anyone have any hints > to find the best tools to do some benchmarking with? > > You made the point, Ildiko, I was on a long-running time-off so I didn't had time to look at your question yet. Good concern tho, I have no knowledge about this, but I can ping a few other folks to get you an answer. -Sylvain Thanks, > Ildikó > > > > On Aug 9, 2021, at 08:46, Ildiko Vancsa wrote: > > > > 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ó > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Tue Aug 31 15:19:54 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Tue, 31 Aug 2021 12:19:54 -0300 Subject: [cinder][nova] fsfreeze hooks issues with cinder snapshot/backup In-Reply-To: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> References: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> Message-ID: Hello, As far as I can see cinder hasn't implemented this. However, I'm not sure about the status of this feature because the last update was on 2014[1] I think it's important to mention that this would only affect the live snapshots (handled by Nova) but for any other scenario every cinder driver optimized the snapshot/backup creation in a different way. This sounds like a good PTG discussion topic. You can add it to the planning etherpad here: https://etherpad.opendev.org/p/yoga-ptg-cinder-planning There's also info about the dates and times we'll be meeting on that etherpad. Cheers, Sofia [1] https://blueprints.launchpad.net/cinder/+spec/quiesced-snapshots-with-qemu-guest-agent On Tue, Aug 31, 2021 at 11:52 AM Arthur Outhenin-Chalandre < arthur.outhenin-chalandre at cern.ch> wrote: > Hello, > > We are trying to trigger an fsfreeze via a cinder backup or snapshot. We > confirmed that the fsfreeze hooks are actually called with a nova > snapshot with `/var/log/qga-fsfreeze-hook.log` in the VM, but we can't > achieve the same thing with a cinder backup/snapshot attached to the > same instance. We are using Wallaby, libvirt, RBD for cinder volumes and > RBD as well for cinder-backup. > > According to this (old) spec [0], cinder should call the `quiesce()` > method in nova during backup/snapshot. We looked in the cinder code and > couldn't find any clear evidence that this method is actually called by > cinder (but we may have missed something). We added some debug messages > on quiesce/can_quiesce/require_quiesce/... in > `nova/virt/libvirt/driver.py` and they are never called with a cinder > backup/snapshot in our setup while they are (and succeed) if we do a > nova snapshot. > > We are starting to suspect that something is missing in cinder, but it > could very well be a problem with our setup as well... Does someone use > this feature or know if it should be working/implemented? > > [0]: > > https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent#Cinder > > Cheers, > > -- > Arthur Outhenin-Chalandre > > -- 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 sbauza at redhat.com Tue Aug 31 15:21:14 2021 From: sbauza at redhat.com (Sylvain Bauza) Date: Tue, 31 Aug 2021 17:21:14 +0200 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: References: Message-ID: On Tue, Aug 31, 2021 at 5:10 PM Sylvain Bauza wrote: > > > On Tue, Aug 31, 2021 at 4:34 PM Ildiko Vancsa > wrote: > >> Hi, >> >> As we are approaching the end of the holiday season I wanted to surface >> back my question about GPU performance testing. Does anyone have any hints >> to find the best tools to do some benchmarking with? >> >> > > You made the point, Ildiko, I was on a long-running time-off so I didn't > had time to look at your question yet. > > Good concern tho, I have no knowledge about this, but I can ping a few > other folks to get you an answer. > Btw, I can understand this can be a frustrating by short answer, so I'll develop. Technically, benchmarking is a huge word : depending on your usecase, performance can very differ for the same card (take the general example of CPU-bound vs. IO-bound tasks and you get the idea for GPUs) For this reason, I'd recommend you to first consider the metrics you'd like to stress on and only then identify the tools than can sustain your needs. For a standard test which can be errorprone but still a bit interesting, I'd propose you to run a couple of tensorflow examples against different environments (one with baremetal GPU, one with passthrough, one with virtual GPUs on Nova directly, one with Cyborg). This would give you the idea of the performance penalities but I suspect those to be less than minor. For real benchmarking cases, I can't answer, hence my call to other folks. By the way, I know CERN invested a bit into HPC testing with GPUs, maybe someone from their team or someone from the related Scientific WG could provide more insights ? -Sylvain -Sylvain > > Thanks, >> Ildikó >> >> >> > On Aug 9, 2021, at 08:46, Ildiko Vancsa >> wrote: >> > >> > 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ó >> > >> > >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Aug 31 17:02:17 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 31 Aug 2021 12:02:17 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Sept 2nd at 1500 UTC Message-ID: <17b9d29598c.1049f1a9c135562.7894740217587346102@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Sept 2nd at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Sept 1st, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From feilong at catalyst.net.nz Tue Aug 31 19:52:39 2021 From: feilong at catalyst.net.nz (feilong) Date: Wed, 1 Sep 2021 07:52:39 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Hi Karea, Given you can see heat-container-agent container from podman which means you should be able to see logs from below path: [root at k8s-100-eh6s5l6d73ie-master-0 heat-config-script]# ls c64e6ac2-db7e-4786-a387-1d45359812b8-k8s-100-eh6s5l6d73ie-kube_cluster_config-uxpsylgnayjy.log fa1f6247-51a8-4e70-befa-cbc61ee99e59-k8s-100-eh6s5l6d73ie-kube_masters-kmi423lgbjw3-0-oii7uzemq7aj-master_config-dhfam54i456j.log [root at k8s-100-eh6s5l6d73ie-master-0 heat-config-script]# pwd /var/log/heat-config/heat-config-script If you can not see the path and the log, then it means the heat-container-agent didn't work well. You need to check the service status by systemctl command and check the log by journalctl. From there, you should be able to see why the cluster failed. On 1/09/21 1:41 am, Karera Tony wrote: > Dear Ammad, > > Sorry to bother you again but I have failed to get the right > command to use to check. > > Every Kubectl command I run on either the master or worker. > The connection to the server localhost:8080 was refused - did you > specify the right host or port? > I get the error below. > > > Regards > > Tony Karera > > > > > On Fri, Aug 27, 2021 at 9:15 AM Ammad Syed > wrote: > > Your hyperkube services are not started. > > You need to check hyperkube services. > > Ammad > > On Fri, Aug 27, 2021 at 10:35 AM Karera Tony > wrote: > > Dear Ammad, > > Below is the output of podman ps > > CONTAINER ID  IMAGE                                           >                  COMMAND               CREATED       STATUS   >         PORTS       NAMES > 319fbebc2f50 >  docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 > >  /usr/bin/start-he...  23 hours ago  Up 23 hours ago           >    heat-container-agent > [root at k8s-cluster-2-4faiphvzsmzu-master-0 core]# > > > Regards > > Tony Karera > > > > > On Thu, Aug 26, 2021 at 9:54 AM Ammad Syed > > wrote: > > The output in > logfile 29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd > is incomplete. > > There should be the installation and configuration of many > other things that are missing. Also it looks that > hyperkube is not installed. > > Can you check the response of "podman ps" command on > master nodes.  > > Ammad  > > On Thu, Aug 26, 2021 at 11:30 AM Karera Tony > > wrote: > > Here is the beginning of the Log > > Starting to run kube-apiserver-to-kubelet-role > + echo 'Waiting for Kubernetes API...' > Waiting for Kubernetes API... > ++ kubectl get --raw=/healthz > The connection to the server localhost:8080 was > refused - did you specify the right host or port? > + '[' ok = '' ']' > > > Regards > > Tony Karera > > > > > On Thu, Aug 26, 2021 at 7:53 AM Bharat Kunwar > > wrote: > > I assume these are from the master nodes? Can you > share the logs shortly after creation rather than > when it times out? I think there is some missing > logs from the top. > > Sent from my iPhone > >> On 26 Aug 2021, at 06:14, Karera Tony >> > > wrote: >> >>  >> Hello Guys, >> >> Attached are the two logs from the >> /var/log/heat-config/heat-config-script directory >> Regards >> >> Tony Karera >> >> >> >> >> On Thu, Aug 26, 2021 at 5:59 AM Karera Tony >> > > wrote: >> >> Dear Sir, >> >> You are right. >> >> I am getting this error >> >> kubectl get --raw=/healthz >> The connection to the server localhost:8080 >> was refused - did you specify the right host >> or port? >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Aug 25, 2021 at 10:55 PM Bharat >> Kunwar > > wrote: >> >> I’d check the logs under >> /var/log/heat-config. >> >> Sent from my iPhone >> >>> On 25 Aug 2021, at 19:39, Karera Tony >>> >> > wrote: >>> >>>  >>> DeaR Ammad, >>> >>> I was able to make the communication >>> work and the Worker nodes were created >>> as well but the cluster failed. >>> >>> I logged in to the master node and there >>> was no error but below are the error >>> when I run systemctl status >>> heat-container-agent on the worker noed. >>> >>> Aug 25 17:52:24 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:52:55 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:53:26 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:53:57 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:54:28 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:54:59 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:55:29 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:56:00 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:56:31 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Aug 25 17:57:02 >>> cluster1-fmkpva3nozf7-node-0 >>> podman[2268]: >>> /var/lib/os-collect-config/local-data >>> not found. Skipping >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 10:38 AM Ammad >>> Syed >> > wrote: >>> >>> Yes, keystone, Heat, Barbicane and >>> magnum public endpoints must be >>> reachable from master and worker nodes. >>> >>> You can use below guide for the >>> reference as well. >>> >>> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_victoria4&f=11 >>> >>> Ammad >>> >>> On Wed, Aug 25, 2021 at 12:08 PM >>> Karera Tony >> > wrote: >>> >>> Hello Ammad, >>> >>> I have deployed using the given >>> image but I think there is an >>> issue with keystone as per the >>> screen shot below when I checked >>> the master node's >>> heat-container-agent status >>> >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 8:28 AM >>> Karera Tony >>> >> > >>> wrote: >>> >>> Hello Ammad, >>> >>> I actually first used that >>> one and it was also getting >>> stuck. >>> >>> I will try this one again >>> and update you with the Logs >>> though. >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 at 8:25 >>> AM Ammad Syed >>> >> > >>> wrote: >>> >>> It seems from the logs >>> that you are using >>> fedora atomic. Can you >>> try with FCOS 32 image. >>> >>> https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20201004.3.0/x86_64/fedora-coreos-32.20201004.3.0-openstack.x86_64.qcow2.xz >>> >>> Ammad >>> >>> On Wed, Aug 25, 2021 at >>> 11:20 AM Karera Tony >>> >> > >>> wrote: >>> >>> Hello Sir, >>> >>> Attached is the Log file >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Aug 25, 2021 >>> at 7:31 AM Ammad >>> Syed >>> >> > >>> wrote: >>> >>> Hi Karera, >>> >>> Can you share us >>> the full log file. >>> >>> Ammad >>> >>> On Wed, Aug 25, >>> 2021 at 9:42 AM >>> Karera Tony >>> >> > >>> wrote: >>> >>> Hello Guys, >>> >>> Thanks a lot >>> for the help >>> but >>> unfortunately >>> I dont see >>> much >>> information >>> in the log >>> file >>> indicating a >>> failure >>> apart from >>> the log that >>> keeps appearing. >>> >>> >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Tue, Aug >>> 24, 2021 at >>> 8:12 PM >>> Mohammed >>> Naser >>> >> > >>> wrote: >>> >>> Also >>> check >>> out >>> /var/log/cloud-init.log >>> :) >>> >>> On Tue, >>> Aug 24, >>> 2021 at >>> 1:39 PM >>> Ammad >>> Syed >>> >> > >>> wrote: >>> > >>> > Then >>> check >>> journalctl >>> -xe or >>> status >>> of heat >>> agent >>> service >>> status. >>> > >>> > >>> > Ammad >>> > On >>> Tue, Aug >>> 24, 2021 >>> at 10:36 >>> PM >>> Karera >>> Tony >>> >> > >>> wrote: >>> >> >>> >> Hello >>> Ammad, >>> >> >>> >> There >>> is no >>> directory >>> or log >>> relevant >>> to heat >>> in the >>> /var/log >>> directory >>> >> >>> >> Regards >>> >> >>> >> Tony >>> Karera >>> >> >>> >> >>> >> >>> >> >>> >> On >>> Tue, Aug >>> 24, 2021 >>> at 12:43 >>> PM Ammad >>> Syed >>> >> > >>> wrote: >>> >>> >>> >>> Hi >>> Karera, >>> >>> >>> >>> >>> Login to >>> master >>> node and >>> check >>> the logs >>> of heat >>> agent in >>> var log. >>> There >>> must be >>> something >>> the >>> cluster >>> is >>> stucking >>> somewhere >>> in creating. >>> >>> >>> >>> Ammad >>> >>> >>> >>> On >>> Tue, Aug >>> 24, 2021 >>> at 3:41 >>> PM >>> Karera >>> Tony >>> >> > >>> wrote: >>> >>>> >>> >>>> >>> Hello Ammad, >>> >>>> >>> >>>> I >>> had done >>> as >>> explained >>> and it >>> worked >>> upto a >>> certain >>> point. >>> The >>> master >>> node was >>> created >>> but the >>> cluster >>> remained >>> in >>> Creation >>> in >>> progress >>> for over >>> an hour >>> and >>> failed >>> with >>> error below >>> >>>> >>> >>>> >>> Stack Faults >>> >>>> as >>> follows: >>> >>>> >>> default-master >>> >>>> >>> Timed out >>> >>>> >>> default-worker >>> >>>> >>> Timed out >>> >>>> >>> >>>> >>> >>>> Regards >>> >>>> >>> >>>> >>> Tony Karera >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On >>> Tue, Aug >>> 24, 2021 >>> at 9:25 >>> AM Ammad >>> Syed >>> >> > >>> wrote: >>> >>>>> >>> >>>>> Hi >>> Tony, >>> >>>>> >>> >>>>> >>> You can >>> try by >>> creating >>> your >>> private >>> vxlan >>> network >>> prior to >>> deployment >>> of >>> cluster >>> and >>> explicitly >>> create >>> your >>> cluster >>> in vxlan >>> network. >>> >>>>> >>> >>>>> >>> --fixed-network >>> private >>> --fixed-subnet >>> private-subnet >>> >>>>> >>> >>>>> >>> You can >>> specify >>> above >>> while >>> creating >>> a cluster. >>> >>>>> >>> >>>>> Ammad >>> >>>>> >>> >>>>> On >>> Tue, Aug >>> 24, 2021 >>> at 11:59 >>> AM >>> Karera >>> Tony >>> >> > >>> wrote: >>> >>>>>> >>> >>>>>> >>> Hello >>> MOhamed, >>> >>>>>> >>> >>>>>> I >>> think >>> the >>> Kubernetes >>> cluster >>> is ok >>> but it >>> when I >>> deploy >>> it, It >>> creates >>> a fixed >>> network >>> using >>> vlan >>> which I >>> am not >>> using >>> for >>> internal >>> networks. >>> >>>>>> >>> >>>>>> >>> When I >>> create a >>> a vxlan >>> Network >>> and use >>> it in >>> the >>> cluster >>> creation, >>> It >>> fails. >>> Is there >>> a trick >>> around >>> this ? >>> >>>>>> >>> Regards >>> >>>>>> >>> >>>>>> >>> Tony Karera >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> On Fri, >>> Aug 20, >>> 2021 at >>> 9:00 AM >>> feilong >>> >> > >>> wrote: >>> >>>>>>> >>> >>>>>>> >>> 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. >>> >>>>>>> >>> ------------------------------------------------------------------------------ >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> >>> Regards, >>> >>>>> >>> >>>>> >>> >>>>> >>> Syed >>> Ammad Ali >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> >>> >>> >>> >>> Syed >>> Ammad Ali >>> > >>> > -- >>> > Regards, >>> > >>> > >>> > Syed >>> Ammad Ali >>> >>> >>> >>> -- >>> Mohammed >>> Naser >>> VEXXHOST, >>> Inc. >>> >>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >>> >>> >>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> <29a37aff-f1f6-46b3-8541-887491c6cfe8-k8s-cluster3-dcu52bgzpbuu-kube_masters-ocfrn2ikpcgd-0-32tmkqgdq7wl-master_config-gihyfv3wlyzd.log> >> <6fca39b1-8eda-4786-8424-e5b04434cce7-k8s-cluster3-dcu52bgzpbuu-kube_cluster_config-aht4it6p7wfk.log> > > > > -- > Regards, > > > Syed Ammad Ali > > -- > Regards, > > > Syed Ammad Ali > -- 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 paolo at celati.com Tue Aug 31 22:14:03 2021 From: paolo at celati.com (Paolo Celati) Date: Wed, 1 Sep 2021 00:14:03 +0200 Subject: [kolla-ansible] Running Docker Swarm with Kuryr networking Message-ID: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Hi,   long story short I have a 3 node Openstack cluster that I manage with kolla-ansible, and I'd like to run Docker Swarm on that as well.  I am aware Magnum exists, but I'd first like to get my head around this simpler case. Seeing as I'd like to connect Docker containers from swarm compose files to Neutron networks I'm trying to set up Kuryr together with a swarm configuration.  However the documentation is a little scarce and I'd prefer running everything on these three hosts, including etcd.  If I follow the guide and pass --cluster-store and --cluster-advertise arguments to dockerd then I can't run Docker in Swarm mode because I get an error saying Swarm is incompatible with those options, and at the same time it's not clear from documentation how you are expected to do Kuryr+Swarm.  I did initialise the Swarm cluster before trying to add Kuryr, so I don't know if perhaps doing this the other way works?  Do you have ideas or advice with this scenario?  If worst comes to worst I can set up an external etcd cluster on a separate non-Openstack cluster but I'd rather avoid that. Thanks in advance, Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x6A5811658B827BE4.asc Type: application/pgp-keys Size: 3123 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ildiko.vancsa at gmail.com Tue Aug 31 23:02:19 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 31 Aug 2021 16:02:19 -0700 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: References: Message-ID: Hi Sylvain, […] > > Technically, benchmarking is a huge word : depending on your usecase, performance can very differ for the same card (take the general example of CPU-bound vs. IO-bound tasks and you get the idea for GPUs) > For this reason, I'd recommend you to first consider the metrics you'd like to stress on and only then identify the tools than can sustain your needs. That is a very good point. The scope is very much around basic validation of new GPU HW in an OpenStack environment with both virtual and passthrough setup. > For a standard test which can be errorprone but still a bit interesting, I'd propose you to run a couple of tensorflow examples against different environments (one with baremetal GPU, one with passthrough, one with virtual GPUs on Nova directly, one with Cyborg). This would give you the idea of the performance penalities but I suspect those to be less than minor. That sounds like a good starting point for a basic setup, I will pass the info along. Thank you! > For real benchmarking cases, I can't answer, hence my call to other folks. By the way, I know CERN invested a bit into HPC testing with GPUs, maybe someone from their team or someone from the related Scientific WG could provide more insights ? I did find a few CERN slides and videos, but they were a few years old so I thought to drop in the question here as well to see if there are any new tools or methods to consider. Thanks, Ildikó > > -Sylvain > > > > On Aug 9, 2021, at 08:46, Ildiko Vancsa wrote: > > > > 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 moreira.belmiro.email.lists at gmail.com Tue Aug 31 23:50:37 2021 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Wed, 1 Sep 2021 01:50:37 +0200 Subject: Subject: [all][elections][ptl] PTL Voting Kickoff - Cyborg Message-ID: Polls for PTL elections are now open and will remain open for you to cast your vote until Sep 07, 2021 23:45 UTC. We are having PTL elections for Cyborg. Please rank all candidates in your order of preference. You are eligible to vote in a PTL election if you are a Foundationindividual member[0] and had a commit in one of that team'sdeliverable repositories[1] over the Sep 25, 2020 00:00 UTC - Aug 24, 2021 00:00 UTC timeframe (Wallaby to Xena) or if you are in that team's list of extra-atcs[2]. If you are eligible to vote in an election, you should find youremail with a link to the Condorcet page to cast your vote in theinbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in atleast one of the projects having an election:* check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam* wait a bit and check again, in case your email server is a bit slow* find the sha of at least one commit from the project's deliverable repos[0] and email the election officials[4]. If we can confirm that you are entitled to vote, we will add youto the voters list for the appropriate election. Our democratic process is important to the health of OpenStack,please exercise your right to vote! Candidate statements/platforms can be found linked to Candidatenames on this page:https://governance.openstack.org/election/ Happy voting,Belmiro,On behalf of all the Election Officials [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/0.10.0/reference/projects.yaml [2] Look for the extra-atcs element in [1] [3] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [4] https://governance.openstack.org/election/#election-officials -------------- next part -------------- An HTML attachment was scrubbed... URL: