From moreira.belmiro.email.lists at gmail.com Wed Sep 1 00:03:00 2021 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Wed, 1 Sep 2021 02:03:00 +0200 Subject: Subject: [all][elections][ptl] PTL Voting Kickoff - Cyborg In-Reply-To: References: Message-ID: (resending to fix the format) 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 Foundation individual member[0] and had a commit in one of that team's deliverable 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 your email with a link to the Condorcet page to cast your vote in the inbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in at least 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 you to 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 Candidate names 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 On Wed, Sep 1, 2021 at 1:50 AM Belmiro Moreira < moreira.belmiro.email.lists at gmail.com> wrote: > 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: From zhangbailin at inspur.com Wed Sep 1 01:55:18 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Wed, 1 Sep 2021 01:55:18 +0000 Subject: =?gb2312?B?tPC4tDogW25vdmFdW2N5Ym9yZ11bZ3B1XSBHUFUgcGVyZm9ybWFuY2UgdGVz?= =?gb2312?Q?ting?= In-Reply-To: References: Message-ID: <4e79976a887b41f4a04ecf788eb5e87a@inspur.com> > one with baremetal GPU, one with passthrough, one with virtual GPUs on Nova directly, one with Cyborg Agree with Sylvain Bauza, if you want to test the GPU performance you can use benchmarking, but performance may be related to the running business. Whether it is through nova or cyborg, the GPU is bound, and there should be little difference in performance. brinzhang Inspur Electronic Information Industry Co.,Ltd. 发件人: Sylvain Bauza [mailto:sbauza at redhat.com] 发送时间: 2021年8月31日 23:21 收件人: Ildiko Vancsa 抄送: OpenStack Discuss 主题: Re: [nova][cyborg][gpu] GPU performance testing 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 sz_cuitao at 163.com Wed Sep 1 03:16:47 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Wed, 1 Sep 2021 11:16:47 +0800 Subject: How to stop the whole system gracefully ? In-Reply-To: References: <00af01d79d61$1adb57d0$50920770$@163.com> <010b01d79e05$8719a970$954cfc50$@163.com> Message-ID: <004701d79edf$cce9f7e0$66bde7a0$@163.com> 1. Do I need to back up the current Mariadb before performing mariadB_recovery? Otherwise what backup is this command based on to restore the database? 2. After the stop command is run, the container stops, but is the configuration information deleted? Does re-running deploy-containers simply pull up the container? Will the configuration information also be overwritten? -----Original Message----- From: Sean Mooney Sent: Tuesday, August 31, 2021 6:08 PM To: Tommy Sway ; 'openstack-discuss' Subject: Re: How to stop the whole system gracefully ? 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 rosmaita.fossdev at gmail.com Wed Sep 1 05:21:56 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 1 Sep 2021 01:21:56 -0400 Subject: [cinder] final Xena cinderclient reviews Message-ID: Consistent with our goal to have the Xena cinderclient support Block Storage API v. 3.66, please focus on these patches: https://review.opendev.org/c/openstack/cinder/+/789564 https://review.opendev.org/c/openstack/python-cinderclient/+/806817/ cheers, brian From skaplons at redhat.com Wed Sep 1 06:46:50 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 01 Sep 2021 08:46:50 +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: <11196443.jP3EJilxpz@p1> Hi, On poniedziałek, 30 sierpnia 2021 16:23:36 CEST Herve Beraud wrote: > 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. I already proposed new release of the ovn-octavia-provider (1.1.1) [1] and it's done. But TBH I'm a bit confused as we had already version 1.1.0 released in Xena cycle some time ago - see [2]. So I'm not really sure why this project is on that list now :) [1] https://review.opendev.org/c/openstack/releases/+/806716 [2] https://review.opendev.org/c/openstack/releases/+/803321 -- 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 hberaud at redhat.com Wed Sep 1 07:49:33 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 1 Sep 2021 09:49:33 +0200 Subject: [release][heat][ironic][requirements][swift][OpenStackSDK][vitrage][barbican][heat][horizon][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: <11196443.jP3EJilxpz@p1> References: <11196443.jP3EJilxpz@p1> Message-ID: Le mer. 1 sept. 2021 à 08:47, Slawek Kaplonski a écrit : > Hi, > > On poniedziałek, 30 sierpnia 2021 16:23:36 CEST Herve Beraud wrote: > > 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. > > I already proposed new release of the ovn-octavia-provider (1.1.1) [1] and > it's done. > But TBH I'm a bit confused as we had already version 1.1.0 released in > Xena > cycle some time ago - see [2]. So I'm not really sure why this project is > on > that list now :) > Indeed you are right our tooling used to generate this list missed this point. I'll try to see why it didn't ignored ovn-octavia-provider. Thanks for the heads up. > [1] https://review.opendev.org/c/openstack/releases/+/806716 > [2] https://review.opendev.org/c/openstack/releases/+/803321 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -- 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 hberaud at redhat.com Wed Sep 1 07:58:34 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 1 Sep 2021 09:58:34 +0200 Subject: [release][heat][ironic][requirements][OpenStackSDK][barbican][heat][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: References: <11196443.jP3EJilxpz@p1> Message-ID: Well, the projects below could also ignore this thread, they are in the same case that the ovn-octavia-provider. For more details see the previous messages of this discussion. - horizon - swift - tempest - vitrage-dashboard - vitrage I remove these teams from the subject of this thread. Thanks for your attention. Le mer. 1 sept. 2021 à 09:49, Herve Beraud a écrit : > > > Le mer. 1 sept. 2021 à 08:47, Slawek Kaplonski a > écrit : > >> Hi, >> >> On poniedziałek, 30 sierpnia 2021 16:23:36 CEST Herve Beraud wrote: >> > 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. >> >> I already proposed new release of the ovn-octavia-provider (1.1.1) [1] >> and >> it's done. >> But TBH I'm a bit confused as we had already version 1.1.0 released in >> Xena >> cycle some time ago - see [2]. So I'm not really sure why this project is >> on >> that list now :) >> > > Indeed you are right our tooling used to generate this list missed this > point. I'll try to see why it didn't ignored ovn-octavia-provider. > Thanks for the heads up. > > >> [1] https://review.opendev.org/c/openstack/releases/+/806716 >> [2] https://review.opendev.org/c/openstack/releases/+/803321 >> >> -- >> Slawek Kaplonski >> Principal Software Engineer >> Red Hat > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > > -- 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 hjensas at redhat.com Wed Sep 1 08:13:49 2021 From: hjensas at redhat.com (Harald Jensas) Date: Wed, 1 Sep 2021 10:13:49 +0200 Subject: Need some help to understand "Baremetal Provision Configuration" file In-Reply-To: References: <41c7ae92-eee6-87c6-c232-6410579fe901@redhat.com> Message-ID: <50502e08-8635-7ef1-6c21-2a563c89a283@redhat.com> On 8/28/21 12:40 AM, wodel youchi wrote: > 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 Remove the subnet line from the entry with 'vif: true'. >      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 with ^^ in place you should no longer see the error: "AnsibleUndefinedVariable: 'bond_interface_ovs_options' >      default_route_network: >      - external > - name: ComputeHCI >  count: 3 >  defaults: >    networks: >    - network: ctlplane >      subnet: ctlplane_subnet Remove the subnet line from the entry with 'vif: true'. >      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 > > From manchandavishal143 at gmail.com Wed Sep 1 08:19:41 2021 From: manchandavishal143 at gmail.com (vishal manchanda) Date: Wed, 1 Sep 2021 13:49:41 +0530 Subject: [release][heat][ironic][requirements][OpenStackSDK][barbican][heat][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: References: <11196443.jP3EJilxpz@p1> Message-ID: Hi Herve, Same for the horizon as well like horizon already had version 20.0.0(first release for Xena) [1]. Do you still want me to cut a new release? [1] https://review.opendev.org/c/openstack/releases/+/802446 Thanks & Regards, Vishal Manchanda On Wed, Sep 1, 2021 at 1:29 PM Herve Beraud wrote: > Well, the projects below could also ignore this thread, they are in the > same case that the ovn-octavia-provider. For more details see the previous > messages of this discussion. > > - horizon > - swift > - tempest > - vitrage-dashboard > - vitrage > > I remove these teams from the subject of this thread. > Thanks for your attention. > > Le mer. 1 sept. 2021 à 09:49, Herve Beraud a écrit : > >> >> >> Le mer. 1 sept. 2021 à 08:47, Slawek Kaplonski a >> écrit : >> >>> Hi, >>> >>> On poniedziałek, 30 sierpnia 2021 16:23:36 CEST Herve Beraud wrote: >>> > 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. >>> >>> I already proposed new release of the ovn-octavia-provider (1.1.1) [1] >>> and >>> it's done. >>> But TBH I'm a bit confused as we had already version 1.1.0 released in >>> Xena >>> cycle some time ago - see [2]. So I'm not really sure why this project >>> is on >>> that list now :) >>> >> >> Indeed you are right our tooling used to generate this list missed this >> point. I'll try to see why it didn't ignored ovn-octavia-provider. >> Thanks for the heads up. >> >> >>> [1] https://review.opendev.org/c/openstack/releases/+/806716 >>> [2] https://review.opendev.org/c/openstack/releases/+/803321 >>> >>> -- >>> Slawek Kaplonski >>> Principal Software Engineer >>> Red Hat >> >> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> >> > > -- > 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 hberaud at redhat.com Wed Sep 1 08:36:49 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 1 Sep 2021 10:36:49 +0200 Subject: [release][heat][ironic][requirements][OpenStackSDK][barbican][heat][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: References: <11196443.jP3EJilxpz@p1> Message-ID: Yes, thanks. This is why I removed horizon from the list in my previous message http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024583.html We will propose a last release round for the cycle-with-intermediary projects in 2 weeks (during R-3). Horizon will be in the lot. If you feel you need to release more early than R-3, then, fire. Le mer. 1 sept. 2021 à 10:19, vishal manchanda a écrit : > Hi Herve, > > Same for the horizon as well like horizon already had version 20.0.0(first > release for Xena) [1]. > Do you still want me to cut a new release? > > [1] https://review.opendev.org/c/openstack/releases/+/802446 > > Thanks & Regards, > Vishal Manchanda > > On Wed, Sep 1, 2021 at 1:29 PM Herve Beraud wrote: > >> Well, the projects below could also ignore this thread, they are in the >> same case that the ovn-octavia-provider. For more details see the previous >> messages of this discussion. >> >> - horizon >> - swift >> - tempest >> - vitrage-dashboard >> - vitrage >> >> I remove these teams from the subject of this thread. >> Thanks for your attention. >> >> Le mer. 1 sept. 2021 à 09:49, Herve Beraud a écrit : >> >>> >>> >>> Le mer. 1 sept. 2021 à 08:47, Slawek Kaplonski a >>> écrit : >>> >>>> Hi, >>>> >>>> On poniedziałek, 30 sierpnia 2021 16:23:36 CEST Herve Beraud wrote: >>>> > 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. >>>> >>>> I already proposed new release of the ovn-octavia-provider (1.1.1) [1] >>>> and >>>> it's done. >>>> But TBH I'm a bit confused as we had already version 1.1.0 released in >>>> Xena >>>> cycle some time ago - see [2]. So I'm not really sure why this project >>>> is on >>>> that list now :) >>>> >>> >>> Indeed you are right our tooling used to generate this list missed this >>> point. I'll try to see why it didn't ignored ovn-octavia-provider. >>> Thanks for the heads up. >>> >>> >>>> [1] https://review.opendev.org/c/openstack/releases/+/806716 >>>> [2] https://review.opendev.org/c/openstack/releases/+/803321 >>>> >>>> -- >>>> Slawek Kaplonski >>>> Principal Software Engineer >>>> Red Hat >>> >>> >>> >>> -- >>> Hervé Beraud >>> Senior Software Engineer at Red Hat >>> irc: hberaud >>> https://github.com/4383/ >>> https://twitter.com/4383hberaud >>> >>> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> >> -- 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 mark at stackhpc.com Wed Sep 1 08:52:29 2021 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 1 Sep 2021 09:52:29 +0100 Subject: [nova][cinder][barbican] storing secrets in service project In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 at 14:50, 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. > > 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. Some loosely-related context: There are certainly some operational issues when using encrypted volumes. In a recent project we used custom policy to meet the requirements to avoid some issues. We configured nova & cinder to send a service token to barbican, and configured the barbican policy to only allow secret decryption for certain combinations of user roles and service roles. This allows an operator with a particular role to migrate another user's instance, but prevents them from reading the secret directly since they wouldn't have the service role. Unfortunately it was not possible to do the same for barbican secrets since there is a hard coded project check in the barbican DB layer which bypasses policy. Some related patches: * https://review.opendev.org/c/openstack/castellan/+/769560 * https://review.opendev.org/c/openstack/nova/+/781079 Other patches are yet to make it out of the environment. > > Best regards, > Pavlo. From arthur.outhenin-chalandre at cern.ch Wed Sep 1 09:23:03 2021 From: arthur.outhenin-chalandre at cern.ch (Arthur Outhenin-Chalandre) Date: Wed, 1 Sep 2021 11:23:03 +0200 Subject: [cinder][nova] fsfreeze hooks issues with cinder snapshot/backup In-Reply-To: References: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> Message-ID: Hello, On 8/31/21 5:19 PM, Sofia Enriquez wrote: > 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] Oh ok, I was hoping it was a setup problem on our side. Thanks for letting me know, it has saved me from further testing/research! > 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. I added the discussion topic and I will be around to discuss it. I should be able to participate in the dev if needed as well. Cheers, -- Arthur Outhenin-Chalandre From lyarwood at redhat.com Wed Sep 1 10:20:21 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Wed, 1 Sep 2021 11:20:21 +0100 Subject: [cinder][nova] fsfreeze hooks issues with cinder snapshot/backup In-Reply-To: References: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> Message-ID: <20210901102021.7pdpozvq4u36nunl@lyarwood-laptop.usersys.redhat.com> On 31-08-21 12:19:54, Sofia Enriquez wrote: > 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] Oddly enough imageCreate [1] in Nova does orchestrate this when creating image based snapshots of volume backed instances [2] when called directly. Nova doesn't provide an external API to quiesce an instance so outside of the imageCreate and os-assisted-volume-snapshots [3][4] (only used by the NFS c-vol backend) flows it isn't going to happen. [1] https://docs.openstack.org/api-ref/compute/?expanded=create-image-createimage-action-detail#create-image-createimage-action [2] https://github.com/openstack/nova/blob/e81211318a29c5f07ee2b9c753dbab041ee01c21/nova/compute/api.py#L3353-L3383 [3] https://docs.openstack.org/api-ref/compute/#assisted-volume-snapshots-os-assisted-volume-snapshots [4] https://github.com/openstack/nova/blob/e81211318a29c5f07ee2b9c753dbab041ee01c21/nova/virt/libvirt/driver.py#L3346-L3367 > 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. Well to be clear this specific problem is with Cinder orchestrated live attached volume snapshots of non-NFS backends. > 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 I'll add the above to the pad and will try to attend as this will require work on the Nova side to provide an external API or preferably an os-server-external-events event to quiesce the instance. Cheers, Lee > 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 > > -- 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 eblock at nde.ag Wed Sep 1 12:02:25 2021 From: eblock at nde.ag (Eugen Block) Date: Wed, 01 Sep 2021 12:02:25 +0000 Subject: Cinder API timeout on single-control node Message-ID: <20210901120225.Horde.Fyn_birethoRxxPJpwzbF3O@webmail.nde.ag> Hi *, since your last responses were quite helpful regarding rabbitmq I would like to ask a different question for the same environment. It's an older openstack version (Pike) running with only one control node. There already were lots of volumes (way more than 1000) in that cloud, but after adding a bunch more (not sure how many exactly) in one project the whole cinder api became extremely slow. Both horizon and CLI run into timeouts: [Wed Sep 01 13:18:52.109178 2021] [wsgi:error] [pid 60440] [client :58474] Timeout when reading response headers from daemon process 'horizon': /srv/www/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi, referer: http:///project/volumes/ [Wed Sep 01 13:18:53.664714 2021] [wsgi:error] [pid 13007] Not Found: /favicon.ico Sometimes the volume creation succeeds if you just retry, but it often fails. The dashboard shows a "504 gateway timeout" after two minutes (also after four minutes after I increased the timeout for the apache dashboard config). The timeout also shows even if I try to get into the volumes tab of an empty project. A couple of weeks ago I already noticed some performance issues with cinder api if there are lots of attached volumes, if there are many "available" volumes it doesn't seem to slow things down. But since then the total number of volumes has doubled. At the moment there are more than 960 attached volumes across all projects and more than 750 detached volumes. I searched the cinder.conf for any helpful setting but I'm not sure which would actually help. And since it's a production cloud I would like to avoid restarting services all the time just to try something. Maybe some of you can point me in the right direction? I would appreciate any help! If there's more information I can provide just let me know. Thanks! Eugen From joykechen at 163.com Wed Sep 1 12:37:47 2021 From: joykechen at 163.com (=?GBK?B?s8K/yw==?=) Date: Wed, 1 Sep 2021 20:37:47 +0800 (CST) Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: References: Message-ID: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> Hi, I recommend a tool to test GPU performance, which depends on CUDA installation. link: https://github.com/GPUburn/gpuburn/tree/master/GPUBurn Thanks, Ke Chen 在 2021-08-31 23:10:03，"Sylvain Bauza" 写道： 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 joykechen at 163.com Wed Sep 1 12:28:14 2021 From: joykechen at 163.com (=?GBK?B?s8K/yw==?=) Date: Wed, 1 Sep 2021 20:28:14 +0800 (CST) Subject: [all][elections][ptl] PTL Voting - Cyborg - Ke Chen Message-ID: <2b3b57b0.6f63.17ba154cbc9.Coremail.joykechen@163.com> Hi, I would like to announce my candidacy for Cyborg PTL for the Yoga cycle, And hope to get your support. As an openstack enthusiast, I have been engaged in openstack for 4 years. I was lucky to make friends with openstack projects such as Cyborg and Watcher in 2018. I met many interesting partners, such as Matt Riedemann, Sundar Nadathur, Huangzhipeng, Liuli, Baoyumeng, Zhurong, Licanwei, Fengshaohe, Wangxinran, Shogo, Zhangbailin, Songwenping and others. You let me see the charm of the community and rigorous working attitude, thanks. In the past two years, except for the watcher project, I spent most of my time dealing with Cyborg. To be honest, I know cyborg very well. At present, Cyborg can manage FPGA, GPU, smartnic and other acceleration devices. Users can create virtual machines with acceleration resources as needed, which is a very cool thing. However, our Cyborg project still has many things to do. In the next y version, I think there are mainly the following five things to do: 1. Optimize the interaction between Nova and cyborg. The existing interface is synchronous call. On cyborg side, we can change synchronization to asynchronous to save the landing time of concurrent virtual machines. 2. Support for more drivers and more universal drivers. At present, vgpu driver is not supported in cyborg. I hope to implement it in the Yoga cycle. 3. Implementation of disable and enable acceleration devices. 4. More bugfix and documentation enhancements. 5. More virtual machine operation support, such as cold migration. I hope we can bring users a more exciting experience in the next Yoga version. Thanks, Ke Chen(chenke) -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 1 13:21:09 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 1 Sep 2021 10:21:09 -0300 Subject: [cinder] Bug deputy report for week of 2021-01-09 Message-ID: This is a bug report from 2021-18-08 to 2021-01-09. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1942077 "Online database schema migrations to Xena always fail". - https://bugs.launchpad.net/cinder/+bug/1942218 "Huawei FC driver cannot co-locate cinder-volume service with computer". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1942095 "powerflex driver: no volume caching after 126 volumes". Assigned to Vladislav Belogrudov. - https://bugs.launchpad.net/cinder/+bug/1942090 "SolidFire retype fails due to volume status as retyping and not available". Assigned to Fábio Oliveira. - https://bugs.launchpad.net/cinder/+bug/1941694 "IBM SVF driver: Detaching from second instance fails for multi-attach volumes". Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1942301 "[synology] embed driver uses the insecure MD5 algorithm". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1941746 "JovianDSS: incorrect operation of ensure export function". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1930267 "ssh exec timeout". Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1942154 " Backup availability_zone is None". 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 smooney at redhat.com Wed Sep 1 13:32:52 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 01 Sep 2021 14:32:52 +0100 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> References: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> Message-ID: On Wed, 2021-09-01 at 20:37 +0800, 陈克 wrote: > Hi, > I recommend a tool to test GPU performance, which depends on CUDA installation. > > > link: https://github.com/GPUburn/gpuburn/tree/master/GPUBurn > > > if youtube hard ware review have show us anything the best way to benchmark gpu hardware is actully to use repsentivte application rather then synteic benchmarks as gpu vendors have a habbit of tuninging the gpu driver to perfrom better in popular syntitich benchmarks. i would suggest selecting a representive set that cover a number of usecase from cad, gaming, to video transcoding to ml (inference and trianing) to compute vission. blender is a popular opensouce 3d modelely software and it provides some in build bench marks that can be used for evaulating the performace of 3d cad and rendering. opencv is a popular toolkit for compute vission and they have a numbner of benchmark examples such as https://docs.opencv.org/4.5.2/dc/d69/tutorial_dnn_superres_benchmark.html on the more pure ml side there are some syntetic benachmarks provided by tensorflow https://github.com/tensorflow/benchmarks/tree/master/perfzero but often a better approch is to use a common opensocue data set and model and messue the time it takes to train the same model with the same data set in differnet environemnts you also want to messure the infernce rate which involved takign a pre trained model and feeding it data form out side of its training set and mesurrign the performance. its important that that model and data used for the inferce is the same used across all your deployments. pytouch is also another popular ai/ml framework that can be used in a simialr way. looking quickly at https://github.com/GPUburn/gpuburn/tree/master/GPUBurn it looks liek its actully not a benchmark utility but instead a stress test tool for mesuring stablity which is a very differnt thing and i dont think it would be helpful in your cases. in fact using it in a public cloud for example could be considered a break of fair use since its really desiing to put the gpu under as much stress as possibel to detect fault hardware which will impact other users of the gpu/ most of the gaming/windows based tool are propritaty which makes them hard to use as benhcmarks in an opensouce project due to licensing so they likely shoudl be avoided. but ya my advice would be dont look for benchmarks in general but look for framworks/tools/applcation that peopel use to do actual useful work that can be sued to executate a repatable action like useing handbrake to transcode a video file form one format to another to messur the hardwarre encoder performance with fixed inputs then use that out in this case transcoding time as one aspect of the performance mesurment to establish your benchmark. > > > > > > Thanks, > Ke Chen > > > > > > > > 在 2021-08-31 23:10:03，"Sylvain Bauza" 写道： > > > > > > 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ó > > > > > > From jungleboyj at gmail.com Wed Sep 1 13:34:49 2021 From: jungleboyj at gmail.com (Jay Bryant) Date: Wed, 1 Sep 2021 08:34:49 -0500 Subject: [cinder][nova] fsfreeze hooks issues with cinder snapshot/backup In-Reply-To: References: <853de0f0-e6ad-142c-4811-cab1fa921c17@cern.ch> Message-ID: <99aef947-9660-fee5-50d3-a1f6de990580@gmail.com> On 8/31/2021 10:19 AM, Sofia Enriquez wrote: > 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 remember being a part of these discussions and the fact that there was interest in getting it working.  I am wondering if this was just a case where no one followed through on implementation. It might be that we encountered an unexpected challenge that I don't remember. Either way, I do agree that this would be a good topic for the PTG. > 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 > > 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 mnasiadka at gmail.com Wed Sep 1 13:57:29 2021 From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=) Date: Wed, 1 Sep 2021 15:57:29 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: Hi Paolo, Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? I would propose the latter. About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. Best regards, Michal On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > 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: From tim.bell at cern.ch Wed Sep 1 14:46:16 2021 From: tim.bell at cern.ch (Tim Bell) Date: Wed, 1 Sep 2021 16:46:16 +0200 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> References: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> Message-ID: <8E5CAEE8-19DC-416F-939E-A7E7A0DF19FD@cern.ch> > On 1 Sep 2021, at 14:37, 陈克 wrote: > > Hi, > I recommend a tool to test GPU performance, which depends on CUDA installation. > > link: https://github.com/GPUburn/gpuburn/tree/master/GPUBurn > gpuburn is also the tool that CERN uses also when new hardware is delivered and we want to check the hardware is working under load. It’s also a good way to stress your PDUs and cooling if you have several cards (see https://indico.cern.ch/event/950196/contributions/3993259/attachments/2113752/3556174/GPUs_in_CERN_IT.pdf) We also have some specific High Energy Physics benchmarks - https://gitlab.cern.ch/hep-benchmarks/hep-workloads-gpu Cheers Tim > > Thanks, > Ke Chen > > > 在 2021-08-31 23:10:03，"Sylvain Bauza" 写道： > > > > 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 mdulko at redhat.com Wed Sep 1 15:23:54 2021 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Wed, 01 Sep 2021 17:23:54 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: <92301d2d1b574d55ff9c5b45ceab80408efdd0b5.camel@redhat.com> On Wed, 2021-09-01 at 15:57 +0200, Michał Nasiadka wrote: > Hi Paolo, > > Would you like to use the Docker engine that is running on the > OpenStack cluster hosts, or create Virtual Machines that will be used > for a Docker Swarm cluster? > I would propose the latter. > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla- > Ansible deployment, so the container images and Ansible deployment > role are provided as-is currently. > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] > tag for visibility. I doubt anybody on the current team has any experience with running Docker's Kuryr. We're focused on kuryr-kubernetes and Kuryr is in de- facto unmaintained state. > Best regards, > > Michal > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > 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 From yumeng_bao at yahoo.com Wed Sep 1 15:39:40 2021 From: yumeng_bao at yahoo.com (yumeng bao) Date: Wed, 1 Sep 2021 23:39:40 +0800 Subject: [all][elections][ptl] PTL Voting - Cyborg - Ke Chen References: Message-ID: Dear Ke， Thanks for your contributions in cyborg ever since 2018, it’s been more than five release cycles past. By reviewing the patches you’ve committed and suggestions you’ve given to the team, it’s obvious you know cyborg very well, from the bottom to up level including GPU,FPGA,SmartNIC drivers to api, as well as interactions with nova and placement. Although I’m not contributing in cyborg anymore due to my job change, I do agree the five things you listed are important for cyborg, and I would like to see them done in the future. So it would be a big vote +1 from my side. Good luck. Regards， Yumeng > On Sep 1, 2021, at 8:29 PM, 陈克 wrote: >  > Hi, > I would like to announce my candidacy for Cyborg PTL for the Yoga cycle, And hope to get your support. > > As an openstack enthusiast, I have been engaged in openstack for 4 years. > I was lucky to make friends with openstack projects such as Cyborg and Watcher in 2018. > > I met many interesting partners, such as Matt Riedemann, Sundar Nadathur, > Huangzhipeng, Liuli, Baoyumeng, Zhurong, Licanwei, Fengshaohe, Wangxinran, > Shogo, Zhangbailin, Songwenping and others. > > You let me see the charm of the community and rigorous working attitude, thanks. > > In the past two years, except for the watcher project, I spent most of my > time dealing with Cyborg. To be honest, I know cyborg very well. > > At present, Cyborg can manage FPGA, GPU, smartnic and other acceleration > devices. Users can create virtual machines with acceleration resources as > needed, which is a very cool thing. > > However, our Cyborg project still has many things to do. > In the next y version, I think there are mainly the following > five things to do: > 1. Optimize the interaction between Nova and cyborg. > The existing interface is synchronous call. On cyborg side, we can change > synchronization to asynchronous to save the landing time of concurrent > virtual machines. > > 2. Support for more drivers and more universal drivers. > At present, vgpu driver is not supported in cyborg. I hope to implement > it in the Yoga cycle. > > 3. Implementation of disable and enable acceleration devices. > > 4. More bugfix and documentation enhancements. > > 5. More virtual machine operation support, such as cold migration. > > I hope we can bring users a more exciting experience in the next Yoga version. > > Thanks, > Ke Chen(chenke) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Sep 1 15:41:56 2021 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 1 Sep 2021 17:41:56 +0200 Subject: [largescale-sig] Next meeting: Sept 1st, 15utc In-Reply-To: <9d0c7f7b-c8cb-9cce-3cb9-0aba854a665d@openstack.org> References: <9d0c7f7b-c8cb-9cce-3cb9-0aba854a665d@openstack.org> Message-ID: <0b18630e-785c-a850-9a7a-ee43617490c3@openstack.org> We held our meeting today. Small attendance, we discussed date andtopic for our next "Large Scale OpenStack" OpenInfra.Live episode. That one will be on Oct 14 and the working topic is around architecture for large scale deployments. You can read the meeting logs at: https://meetings.opendev.org/meetings/large_scale_sig/2021/large_scale_sig.2021-09-01-15.01.html Our next IRC meeting will be Sept 15, at 1500utc on #openstack-operators on OFTC. Regards, -- Thierry Carrez (ttx) From tonykarera at gmail.com Wed Sep 1 01:51:43 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 1 Sep 2021 03:51:43 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Hey Feilong, Thanks a lot. The services are fine and indeed the log files are there in the directory [ /var/log/heat-config/heat-config-script] After checking, the master log is fine but the cluster log has this error below as I had mentioned earlier 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 Tue, Aug 31, 2021 at 9:52 PM feilong wrote: > 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 < >>>>>>>>>>> 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 >> > -- > 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 feilong at catalyst.net.nz Wed Sep 1 02:04:40 2021 From: feilong at catalyst.net.nz (feilong) Date: Wed, 1 Sep 2021 14:04:40 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Hi Karera, Can you please share all the log under /var/log/heat-config/heat-config-script ? Or you can jump in #openstack-containers channel on OFTC, I'm online now. On 1/09/21 1:51 pm, Karera Tony wrote: > Hey Feilong, > > Thanks a lot. > > The services are fine and indeed the log files are there in the > directory [/var/log/heat-config/heat-config-script] > > After checking, the master log is fine but the cluster log has this > error below as I had mentioned earlier > > 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 Tue, Aug 31, 2021 at 9:52 PM feilong > wrote: > > 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. > ------------------------------------------------------------------------------ > -- 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 Wed Sep 1 02:11:54 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 1 Sep 2021 04:11:54 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Hello Feilong, I would be happy to join. Can you please assist with the link . Thanks a lot Regards Tony Karera On Wed, Sep 1, 2021 at 4:04 AM feilong wrote: > Hi Karera, > > Can you please share all the log under /var/log/heat-config/heat-config-script > ? Or you can jump in #openstack-containers channel on OFTC, I'm online now. > > > > On 1/09/21 1:51 pm, Karera Tony wrote: > > Hey Feilong, > > Thanks a lot. > > The services are fine and indeed the log files are there in the directory [ > /var/log/heat-config/heat-config-script] > > After checking, the master log is fine but the cluster log has this error > below as I had mentioned earlier > > 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 Tue, Aug 31, 2021 at 9:52 PM feilong wrote: > >> 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 < >>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>> tonykarera at gmail.com> 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 >>> >> -- >> 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 tonykarera at gmail.com Wed Sep 1 02:27:11 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 1 Sep 2021 04:27:11 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: Attached are the logs Regards Tony Karera On Wed, Sep 1, 2021 at 4:11 AM Karera Tony wrote: > Hello Feilong, > > I would be happy to join. > > Can you please assist with the link . > > Thanks a lot > Regards > > Tony Karera > > > > > On Wed, Sep 1, 2021 at 4:04 AM feilong wrote: > >> Hi Karera, >> >> Can you please share all the log under /var/log/heat-config/heat-config-script >> ? Or you can jump in #openstack-containers channel on OFTC, I'm online now. >> >> >> >> On 1/09/21 1:51 pm, Karera Tony wrote: >> >> Hey Feilong, >> >> Thanks a lot. >> >> The services are fine and indeed the log files are there in the directory >> [/var/log/heat-config/heat-config-script] >> >> After checking, the master log is fine but the cluster log has this error >> below as I had mentioned earlier >> >> 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 Tue, Aug 31, 2021 at 9:52 PM feilong wrote: >> >>> 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 < >>>>>>>>> bharat at stackhpc.com> 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 < >>>>>>>>>> syedammad83 at gmail.com> 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 < >>>>>>>>>>> tonykarera at gmail.com> 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 < >>>>>>>>>>>> tonykarera at gmail.com> 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 >>>> >>> -- >>> 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: 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 feilong at catalyst.net.nz Wed Sep 1 03:30:34 2021 From: feilong at catalyst.net.nz (feilong) Date: Wed, 1 Sep 2021 15:30:34 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: <40105897-286f-f38e-a91a-ffc32da4fc70@catalyst.net.nz> Your cluster failed because of https://github.com/openstack/magnum/blob/master/magnum/drivers/common/templates/kubernetes/fragments/make-cert.sh#L24 So please just remove your label "tls_enabled=true" and try again. On 1/09/21 2:27 pm, Karera Tony wrote: > Attached are the logs > Regards > > Tony Karera > > > > > On Wed, Sep 1, 2021 at 4:11 AM Karera Tony > wrote: > > Hello Feilong, > > I would be happy to join. > > Can you please assist with the link . > > Thanks a lot > Regards > > Tony Karera > > > > > On Wed, Sep 1, 2021 at 4:04 AM feilong > wrote: > > Hi Karera, > > Can you please share all the log under > /var/log/heat-config/heat-config-script ? Or you can jump in > #openstack-containers channel on OFTC, I'm online now. > > > > On 1/09/21 1:51 pm, Karera Tony wrote: >> Hey Feilong, >> >> Thanks a lot. >> >> The services are fine and indeed the log files are there in >> the directory [/var/log/heat-config/heat-config-script] >> >> After checking, the master log is fine but the cluster log >> has this error below as I had mentioned earlier >> >> 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 Tue, Aug 31, 2021 at 9:52 PM feilong >> > wrote: >> >> 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. >> ------------------------------------------------------------------------------ >> > -- > 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 kkchn.in at gmail.com Wed Sep 1 12:32:27 2021 From: kkchn.in at gmail.com (KK CHN) Date: Wed, 1 Sep 2021 18:02:27 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: <0670B960225633449A24709C291A525251C88F34@COM03.performair.local> References: <20210824080849.Horde.RiSp9yA46PcA-BV5WaLQkcq@webmail.nde.ag> <0670B960225633449A24709C291A525251C86EC8@COM03.performair.local> <0670B960225633449A24709C291A525251C88F34@COM03.performair.local> Message-ID: On Fri, Aug 27, 2021 at 11:00 AM wrote: > Kris; > > First, you can add properties during the create command, so steps 1 > through 3 can become: > # openstack image create “M_Windows_VM_NAME_Blaah” --file > Windows_VM_disk.qcow2 \ > --disk-format qcow2 --container-format bare --public --property > hw_firmware_type=uefi \ > --property os_secure_boot=required --property hw_disk_bios=ide > > I am able to import the WIndows VM, which was exported from (Rhvm oVirt) to my openstack(ussuri, qemu-kvm, glance, cinder-ceph ) booted the first bootable disk of this multi disk Windows 2012 RC VM. It has additionally a data disk which is of 9GB of data of 600 GB volume size originally. > Secondly, no. Only the boot image (C: drive) needs the properties. So > any additional disks for the same VM can use a command like this: > I executed this step for the second disk qcow2 image on my Controller node. # openstack image create “M_Windows_VM_NAME_DataDisk2” --file > Windows_VM_disk.qcow2 --disk-format qcow2 --public > > Then the image appears in the Horizon Image section. I tried to create Volume through Horizon GUI with 600 GB disk space allocated , it ran for 10 t0 20 minutes and went to Error state. multiple attempts I have made by deleting each error volume and creating new volume but same result. So I tried to do it through CLI First I listed the images uploaded : by #openstack image list c6695789-8524-446c-98c9-282b2880551c | CMDALocalDBWindowsdisk2 | active // This is the data disk image root at Meghctrl1:/home/cloud# #openstack volume create --image c6695789-8524-446c-98c9-282b2880551c --size 600 --availability-zone nova CMDA_DB_SecDisk_Vol root at Meghctrl1:/home/cloud# openstack volume list +--------------------------------------+----------------------+-----------+------+-------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+----------------------+-----------+------+-------------+ | 32f9452f-368f-4f26-b70d-c066c4c7e01c | CMDA_DB_SecDisk_Vol | available | 600 | | Now I have gone to the Horizon dashboard. I tried to attach this Volume CMDA_DB_SecDisk_Vol to My running Windows VM which is the first disk which was imported and booted successfully . I got the Dashboard Status alert while doing this : " Info: Attaching volume *CMDA_DB_SecDisk_Vol(32f9452f-368f-4f26-b70d-c066c4c7e01c) to instance 6630c9c8-135e-45b7-958b-c563337eb9c4 on /dev/hdb "* But This is not attached to the Running Windows VM. *You can see it is attached to none * root at Meghctrl1:/home/cloud# openstack volume list +--------------------------------------+----------------------+-----------+------+-------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+----------------------+-----------+------+-------------+ | 32f9452f-368f-4f26-b70d-c066c4c7e01c | CMDA_DB_SecDisk_Vol | available | 600 | | | 0c404d4c-1685-4a5a-84ae-1ee413f02f68 | cloudtest_DMS1 | error | 102 | | | e9949f4f-b23a-4a30-8620-5a8d234b523b | DMS_VM_APPLICATION-2 | available | 100 | Here you can see it attached to None. *Also in the horizon dashboard the running instance I clicked for more information : It shows no Volumes attached to this instance. * TestDB_CMDA_disk1 Create Snapshot - Overview - Interfaces - Log - Console - Action Log NameTestDB_CMDA_disk1ID6630c9c8-135e-45b7-958b-c563337eb9c4Description-Project IDb1bf4df41dc34e3ab5c3b0318158263dStatusActiveLockedFalseAvailability Zone novaCreatedSept. 1, 2021, 12:24 p.m.Age5 hours, 9 minutesHostMeghctrl1Specs ------------------------------ Flavor NameMediumFlavor ID5bb6bc50-b2f7-49b2-8f01-7a631af5ff8cRAM4GBVCPUs2 VCPUDisk150GBIP Addresses ------------------------------ Tenant_NW172.16.100.248Security Groups ------------------------------ default - ALLOW IPv6 from default - ALLOW IPv4 icmp to 0.0.0.0/0 - ALLOW IPv4 to 0.0.0.0/0 - ALLOW IPv4 tcp from 0.0.0.0/0 - ALLOW IPv4 icmp from 0.0.0.0/0 - ALLOW IPv4 from default - ALLOW IPv6 to ::/0 Metadata ------------------------------ Key NameTNSDCImage NameCMDALocalDBWindows1 Image ID6437fde7-db0c-4298-9d92-1f70aae3c894Volumes Attached ------------------------------ Volume*No volumes attached.* *Details of the CLI Created disk Volume details which is unable to attach to the running Windows 2012 RC instance is as follows from Horizon GUI* CMDA_DB_SecDisk_Vol Edit Volume - Overview - Snapshots NameCMDA_DB_SecDisk_VolID32f9452f-368f-4f26-b70d-c066c4c7e01cProject ID b1bf4df41dc34e3ab5c3b0318158263dStatusAvailableGroup-Specs ------------------------------ Size600 GiBType__DEFAULT__BootableNoEncryptedNoCreatedSept. 1, 2021, 4:07 p.m.Attachments ------------------------------ Attached To*Not attached*Volume Source ------------------------------ Image Metadata ------------------------------ None What am I doing wrong here ? : any hints or suggestions to add this data disk to the running WIndows instance are most welcome. Or do I need to add the volume to the instance through CLI, from the docs I am seeing this. Will this work for Running Windows VM instances also ? openstack server add volume 84c6e57d-a6b1-44b6-81eb-fcb36afd31b5 \ 573e024d-5235-49ce-8332-be1576d323f8 --device /dev/vdb *Will you advice to attaching the Volume through CLI like the following * #openstack server add volume 6630c9c8-135e-45b7-958b-c563337eb9c4 32f9452f-368f-4f26-b70d-c066c4c7e01c --device /dev/hdb * Will it solve this volume attachment issue ? or seriously am I missing any crucial parameters or steps for attaching the additional disk volumes for Windows VMs?* *Any hints most welcome: Any other information or specific log files I need to post, kindly tell me know the log file names I can post . I am doing it for the first time. * Thanks in advance for your answers. Kris You might consider making sure that these additional images aren't marked > as bootable. > > That said... Have you considered importing the disks directly into Cinder > instead? > > 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 26, 2021 10:04 PM > To: Dominic Hilsbos > Subject: Re: Windows2012 VM image importing and Instance Launch Failure > > Hi Dominic, > For Importing Single disk Windows VM I performed the following steps on > the vhdx to qcow2 converted image > Step 1: > root at Meghctrl1:/home/cloud# openstack image create > “M_Windows_VM_NAME_Blaah” --file Windows_VM_disk.qcow2 > --disk-format qcow2 --container-format bare --public > Step 2: > root at Meghctrl1:/home/cloud# openstack image set --property > hw_firmware_type=uefi --property > os_secure_boot=required My_Windows_VM_NAME_Blaah > Step 3: > root at Meghctrl1:/home/cloud# openstack image set --property > hw_firmware_type=uefi > --property hw_disk_bios=ide MY_Windows_VM_NAME_Blaah > > And I am able to see the image in the Horizon dashboard "image" tab > and launch the instance from there . Everything went fine and I am able to > get the Windows Single Disk VM running. > > Query: > If I have a Multi Disc Windows VM , do I need to perform all the above > three steps for all the qcow2 converted images ? ( For eg: I have a > Database Server , A Windows VM already running in HyperV with two disks ( > 100GB disk and 600 GB another disk image) . So in these two disks > one will be WIndows OS and another will be attached disk without Windows > OS right ? > 1. For the first disk I will perform all the above three steps after > converting it from vhdx to qcow2. So that image will appear in the > horizon and I can launch an instance as I did early for Single Disk Windows > VM. > 2. For the 600 GB second disk (vhdx format) I will convert it to > qcow2 and then do I need to perform all the above three steps exactly ? > Or what changes I need to make in the above steps to import this disk as > this is an additional attached disk in hyperV. > Request your guidance or any suggestions in this regard. > > Thank You, > Kris > > > > 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. > > 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 anyrude10 at gmail.com Wed Sep 1 14:00:08 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Wed, 1 Sep 2021 19:30:08 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi, I tried Creating a config override file at /etc/kolla/config/ironic.conf and specified the below items: [deploy] erase_devices_priority = 0 erase_devices_metadata_priority = 10 With this it took approx 15 mins to complete the process. Now I tried provisioning the Baremetal Node having 2 Hard disk with the above configuration. Below is my observations: On one of the Hard disk, OS was installed. On the other hard drive, we tried mounting it to a particular mount point. Initially, we got an error *"unknown fs type"*. So we formatted the sdb drive in XFS format using mkfs.xfs command (also tried with ext4) and it was successfully mounted then. After this we put some data onto that disk. Now when the baremetal server is recreated ( openstack server delete and then openstack server create), according to my understanding, the data on the 2nd hard drive sdb should remain intact. Only the data on OS should get deleted. But when I tried mounting the 2nd drive again, it gave us the same error *"unknown fs type"* That means without formatting sdb, I am not able to mount it which means I am not able to access my data stored on SDB which ideally should not be the case. Is there any additional setting that we need to do in an ironic in order to make it work? Regards Anirudh Gupta On Mon, Aug 23, 2021 at 1:20 PM Mark Goddard wrote: > > > 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 < >>>>>>>>> anyrude10 at gmail.com> 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 paolo at celati.com Wed Sep 1 15:07:57 2021 From: paolo at celati.com (Paolo Celati) Date: Wed, 1 Sep 2021 17:07:57 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: Hi Michal,   Yes I would rather run all my Docker containers on the physical hosts.  At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that.  I also prefer Swarm because it's a lot simpler for small scale. Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain.  And I don't have lots of spare RAM either as it's a homelab. Thanks for reminding me about tagging correctly, I forgot to put [kuryr].  Ok didn't know about the lack of CI but good to know. Kind regards, Paolo On 01/09/2021 15:57, Michał Nasiadka wrote: > Hi Paolo, > > Would you like to use the Docker engine that is running on the > OpenStack cluster hosts, or create Virtual Machines that will be used > for a Docker Swarm cluster? > I would propose the latter. > > About Kuryr - we don’t have CI coverage for testing Kuryr in > Kolla-Ansible deployment, so the container images and Ansible > deployment role are provided as-is currently. > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] > tag for visibility. > > Best regards, > > Michal > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: >> >> 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 DHilsbos at performair.com Wed Sep 1 16:46:45 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Wed, 1 Sep 2021 16:46:45 +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> <0670B960225633449A24709C291A525251C88F34@COM03.performair.local> Message-ID: <0670B960225633449A24709C291A525251C8ECCC@COM03.performair.local> Kris; This doesn't look like an issue of Windows in OpenStack, it looks like a glance / nova / underlying storage issue. Do you have any images in this cluster that work correctly? Have you checked your glance / storage logs? What storage system do you use with glance? Have you tried working out how to import your disks directly into cinder as a volume? 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, September 1, 2021 5:32 AM To: Dominic Hilsbos; openstack-discuss at lists.openstack.org Subject: Re: Windows2012 VM image importing and Instance Launch Failure On Fri, Aug 27, 2021 at 11:00 AM wrote: Kris; First, you can add properties during the create command, so steps 1 through 3 can become: # openstack image create  “M_Windows_VM_NAME_Blaah” --file Windows_VM_disk.qcow2 \ --disk-format qcow2 --container-format bare --public --property hw_firmware_type=uefi \ --property os_secure_boot=required --property hw_disk_bios=ide I am able to import  the  WIndows VM, which was exported from (Rhvm oVirt)  to  my openstack(ussuri, qemu-kvm, glance, cinder-ceph )  booted the first bootable disk  of this multi disk Windows 2012 RC VM.   It has additionally   a data disk which is of 9GB of data  of  600 GB volume size originally.    Secondly, no.  Only the boot image (C: drive) needs the properties.  So any additional disks for the same VM can use a command like this: I executed this step for the second disk qcow2 image  on my Controller node.  # openstack image create  “M_Windows_VM_NAME_DataDisk2” --file Windows_VM_disk.qcow2 --disk-format qcow2 --public Then the  image appears in the Horizon Image section.  I tried to create Volume through  Horizon GUI  with  600 GB disk space allocated ,  it ran for 10 t0 20 minutes and went to Error state.  multiple attempts I have made by deleting each error volume and creating new volume  but same result.  So I tried to do it through CLI First I listed the images uploaded : by #openstack image list   c6695789-8524-446c-98c9-282b2880551c | CMDALocalDBWindowsdisk2 | active           // This is  the  data disk image root at Meghctrl1:/home/cloud# #openstack volume create --image c6695789-8524-446c-98c9-282b2880551c --size 600  --availability-zone nova CMDA_DB_SecDisk_Vol root at Meghctrl1:/home/cloud# openstack volume list +--------------------------------------+----------------------+-----------+------+-------------+ | ID                                   | Name                 | Status    | Size | Attached to | +--------------------------------------+----------------------+-----------+------+-------------+ | 32f9452f-368f-4f26-b70d-c066c4c7e01c | CMDA_DB_SecDisk_Vol  | available |  600 |             |   Now I have gone to the Horizon dashboard. I tried to attach this Volume  CMDA_DB_SecDisk_Vol  to   My running  Windows VM  which is the first disk which was imported and booted successfully .  I got the Dashboard Status  alert  while doing this :   " Info: Attaching  volume  CMDA_DB_SecDisk_Vol(32f9452f-368f-4f26-b70d-c066c4c7e01c) to instance 6630c9c8-135e-45b7-958b-c563337eb9c4 on      /dev/hdb  "   But This is not attached to the Running Windows VM. You can see it is attached to none   root at Meghctrl1:/home/cloud# openstack volume list +--------------------------------------+----------------------+-----------+------+-------------+ | ID                                   | Name                 | Status    | Size | Attached to | +--------------------------------------+----------------------+-----------+------+-------------+ | 32f9452f-368f-4f26-b70d-c066c4c7e01c | CMDA_DB_SecDisk_Vol  | available |  600 |             | | 0c404d4c-1685-4a5a-84ae-1ee413f02f68 | cloudtest_DMS1       | error     |  102 |             | | e9949f4f-b23a-4a30-8620-5a8d234b523b | DMS_VM_APPLICATION-2 | available |  100 |              Here you can see it attached to None. Also in the horizon dashboard the running instance   I clicked for more information : It shows  no Volumes attached to this instance.  TestDB_CMDA_disk1 Create Snapshot • Overview • Interfaces • Log • Console • Action Log Name TestDB_CMDA_disk1 ID 6630c9c8-135e-45b7-958b-c563337eb9c4 Description - Project ID b1bf4df41dc34e3ab5c3b0318158263d Status Active Locked False Availability Zone nova Created Sept. 1, 2021, 12:24 p.m. Age 5 hours, 9 minutes Host Meghctrl1 Specs ________________________________________ Flavor Name Medium Flavor ID 5bb6bc50-b2f7-49b2-8f01-7a631af5ff8c RAM 4GB VCPUs 2 VCPU Disk 150GB IP Addresses ________________________________________ Tenant_NW 172.16.100.248 Security Groups ________________________________________ default • ALLOW IPv6 from default • ALLOW IPv4 icmp to 0.0.0.0/0 • ALLOW IPv4 to 0.0.0.0/0 • ALLOW IPv4 tcp from 0.0.0.0/0 • ALLOW IPv4 icmp from 0.0.0.0/0 • ALLOW IPv4 from default • ALLOW IPv6 to ::/0 Metadata ________________________________________ Key Name TNSDC Image Name CMDALocalDBWindows1 Image ID 6437fde7-db0c-4298-9d92-1f70aae3c894 Volumes Attached ________________________________________ Volume No volumes attached. Details of the  CLI Created disk Volume details  which is unable to attach to the running Windows 2012 RC instance is as follows from Horizon GUI CMDA_DB_SecDisk_Vol Edit Volume • Overview • Snapshots Name CMDA_DB_SecDisk_Vol ID 32f9452f-368f-4f26-b70d-c066c4c7e01c Project ID b1bf4df41dc34e3ab5c3b0318158263d Status Available Group - Specs ________________________________________ Size 600 GiB Type __DEFAULT__ Bootable No Encrypted No Created Sept. 1, 2021, 4:07 p.m. Attachments ________________________________________ Attached To Not attached Volume Source ________________________________________ Image Metadata ________________________________________ None What am I doing wrong here  ? :  any hints or suggestions  to add this data disk to the running WIndows instance are most welcome.  Or do I need to add the volume to the instance  through CLI,  from the docs  I am seeing this.   Will this  work for  Running Windows VM instances also  ? openstack server add volume 84c6e57d-a6b1-44b6-81eb-fcb36afd31b5 \ 573e024d-5235-49ce-8332-be1576d323f8 --device /dev/vdb Will you advice to  attaching the Volume  through CLI  like the following   #openstack server add volume 6630c9c8-135e-45b7-958b-c563337eb9c4        32f9452f-368f-4f26-b70d-c066c4c7e01c  --device  /dev/hdb    Will  it  solve this volume attachment issue ? or seriously  am I missing any crucial parameters or steps for attaching the additional disk volumes for Windows VMs? Any hints most welcome: Any other information  or  specific log files I need to post,  kindly tell me know  the log file names  I can post .  I am doing it for the first time.  Thanks in advance for your answers. Kris You might consider making sure that these additional images aren't marked as bootable. That said... Have you considered importing the disks directly into Cinder instead? 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 26, 2021 10:04 PM To: Dominic Hilsbos Subject: Re: Windows2012 VM image importing and Instance Launch Failure Hi Dominic, For Importing Single disk Windows VM   I performed the following steps on the  vhdx to qcow2 converted image Step 1: root at Meghctrl1:/home/cloud# openstack image create  “M_Windows_VM_NAME_Blaah”    --file   Windows_VM_disk.qcow2    --disk-format  qcow2   --container-format    bare       --public Step 2: root at Meghctrl1:/home/cloud# openstack image set    --property   hw_firmware_type=uefi   --property os_secure_boot=required    My_Windows_VM_NAME_Blaah  Step 3:  root at Meghctrl1:/home/cloud# openstack image set     --property    hw_firmware_type=uefi      --property    hw_disk_bios=ide     MY_Windows_VM_NAME_Blaah And I am able to see the image in the Horizon dashboard   "image"   tab  and  launch the instance from there . Everything went fine and I am able to get the Windows Single Disk VM running.  Query: If I have a Multi Disc  Windows VM ,   do I need to perform all the above three  steps for  all the   qcow2 converted  images ?  ( For eg:  I have a  Database Server ,  A Windows VM already running in HyperV with two disks  ( 100GB   disk   and 600 GB another disk image) .     So in these two  disks   one will be WIndows OS and another will be attached disk without Windows OS   right ?   1.  For the first disk I will perform all the  above three steps after converting it  from vhdx to  qcow2.  So that image will appear in the horizon and I can launch an instance as I did early for Single Disk Windows VM.        2.  For the 600 GB second disk (vhdx format) I will convert it to qcow2  and then  do I need to perform  all the above three steps exactly ?  Or what changes I need to make in the above steps  to import this disk as this is an additional attached disk in hyperV. Request your guidance or any suggestions in this regard.  Thank You, Kris 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.   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 radoslaw.piliszek at gmail.com Wed Sep 1 17:28:16 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 1 Sep 2021 19:28:16 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: > > Hi Michal, > > Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. > > I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. > > Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. > > Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. We actually *do* test Kuryr in CI - in the Zun scenario - and it works, at least on CentOS, it fails on Ubuntu for some reason but we don't have anyone to take care of that... Zun works using the on-host Docker as you want to do. *But* as Michał Dulko (hah, had to add the surname to differentiate ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, a similar statement applies to Zun... Your mileage may vary but going forward I advise you take the time to learn Kubernetes. As for mixing up Docker Swarm with Kolla Ansible, that's not really supported either. Kolla Ansible is designed to deploy to a bunch of standalone Docker daemons using only host networking. It could work but it's not tested. -yoctozepto > > Kind regards, > > Paolo > > > On 01/09/2021 15:57, Michał Nasiadka wrote: > > Hi Paolo, > > Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? > I would propose the latter. > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. > > Best regards, > > Michal > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > 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 From gmann at ghanshyammann.com Wed Sep 1 20:41:53 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 01 Sep 2021 15:41:53 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Sept 2nd at 1500 UTC In-Reply-To: <17b9d29598c.1049f1a9c135562.7894740217587346102@ghanshyammann.com> References: <17b9d29598c.1049f1a9c135562.7894740217587346102@ghanshyammann.com> Message-ID: <17ba318be97.cc9f4e3e210522.5438255807862395887@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. NOTE: Tomorrow meeting will be a Video call at google meet, joining information are present in 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/ * Leaderless projects ** https://etherpad.opendev.org/p/yoga-leaderless * New project application: 'Venus' ** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html ** https://review.opendev.org/c/openstack/governance/+/804824 * Next step on pain points from projects/SIGs/pop-up (ricolin) ** https://etherpad.opendev.org/p/pain-point-elimination * Propose OpenStack News: Newsletter ** https://etherpad.opendev.org/p/newsletter-openstack-news * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Tue, 31 Aug 2021 12:02:17 -0500 Ghanshyam Mann wrote ---- > 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 ildiko.vancsa at gmail.com Wed Sep 1 22:27:55 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 1 Sep 2021 15:27:55 -0700 Subject: [nova][cyborg][gpu] GPU performance testing In-Reply-To: <8E5CAEE8-19DC-416F-939E-A7E7A0DF19FD@cern.ch> References: <5b765247.6fd1.17ba15d8b43.Coremail.joykechen@163.com> <8E5CAEE8-19DC-416F-939E-A7E7A0DF19FD@cern.ch> Message-ID: <89CAE2E2-C19A-4EE6-8EF3-5373C75FFFB8@gmail.com> Hi, Thank you all for the recommendations and guidance. This is exactly the information I was looking for! :) Best Regards, Ildikó > On Sep 1, 2021, at 07:46, Tim Bell wrote: > > >> On 1 Sep 2021, at 14:37, 陈克 wrote: >> >> Hi, >> I recommend a tool to test GPU performance, which depends on CUDA installation. >> >> link: https://github.com/GPUburn/gpuburn/tree/master/GPUBurn >> > > gpuburn is also the tool that CERN uses also when new hardware is delivered and we want to check the hardware is working under load. > > It’s also a good way to stress your PDUs and cooling if you have several cards (see https://indico.cern.ch/event/950196/contributions/3993259/attachments/2113752/3556174/GPUs_in_CERN_IT.pdf) > > We also have some specific High Energy Physics benchmarks - https://gitlab.cern.ch/hep-benchmarks/hep-workloads-gpu > > Cheers > Tim > >> >> Thanks, >> Ke Chen >> >> >> 在 2021-08-31 23:10:03，"Sylvain Bauza" 写道： >> >> >> >> 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ó >> > >> > >> >> >> >> >> > From zhangbailin at inspur.com Thu Sep 2 01:30:56 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Thu, 2 Sep 2021 01:30:56 +0000 Subject: [all][elections][ptl][cyborg] PTL voting for Cyborg- Bailin Zhang(brinzhang) Message-ID: <686a943fc784425ba3a6defff0fc49c9@inspur.com> Hi all. I was going to attempt to enumerate some sort of grand vision for Cyborg and our priorities for the next cycle. As I thought about it, though, I realized these remain largely the same as they always have been: provide a reliable, scalable, and efficient hardware-accelerated device management platform. In the past, we have added support for GPU, FPGA, NVMe SSD, and will add support for AEP, SPDK and other devices in the future. In order to increase the ability to interact with the VM, we were completed the feature of nova-cyborg interaction in Ussuri release. The exact details of how we do that may vary somewhat from cycle to cycle, and I was completed the support of nova rebuild/evacuate server and shelve/unshelve in the last two releases, which greatly improved the convenience of user operations. Such as the suspend and resume, the PoC code you can review https://review.opendev.org/c/openstack/nova/+/729945. And we also tried to support the code migration in the future, of course that need a spec and to talk with nova team. The log management project (Venus) team and I have completed the integration of Venus to Cyborg. We can use Venus to quickly retrieve Cyborg logs, shorten the problem location time, etc., so as to improve the efficiency of the Cyborg project. In the future, I will have in-depth exchanges with the Venus development team to continue to enhance this feature. In these two releases, I have promoted many newcomers to join the Cyborg team (such as Wenping Song, Eric Xie, fossnqiu, Zhiguang Wang, Arthur Dayne etc.), and they have made great contributions to the Cyborg project. In the future, I would like to help more people. I hope to get your support, thanks. Bailin Zhang (brinzhang) brinzhang Inspur Electronic Information Industry Co.,Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyppe at gmail.com Thu Sep 2 03:50:44 2021 From: tonyppe at gmail.com (Tony Pearce) Date: Thu, 2 Sep 2021 11:50:44 +0800 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: <1701b95c-2cad-c593-e394-1825355e61ea@catalystcloud.nz> References: <85bd5e9e6b4c8e0a60f51f9fd32e170a1d4064ec.camel@mittwald.de> <1701b95c-2cad-c593-e394-1825355e61ea@catalystcloud.nz> Message-ID: Thanks Feilong and Sven. > 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. I thought this too. But when I try and run "check stack" under heat it fails. The log for this failure is that the resource is missing, ie one of the nodes is not there (which I know about). I tried the cluster resize from horizon, to resize the cluster to the valid size / current size (without the additional node failure which is not there) and horizon immediately fails this with a red error in the corner of the web page. There's no log printed within magnum or heat logs at all. And the horizon error is not really helpful with error "*Error: *Unable to resize given cluster id: 1a8e1ed9-64b3-41b1-ab11-0f01e66da1d7.". > Are you using the magnum auto healing feature by chance? The "repair unhealthy nodes" option was chosen for this I believe. But I didnt set up the cluster so I am not sure. Based on your replies, I discovered how to initiate the cluster resize using the CLI. After issuing the command, the missing node was rebuilt immediately. This then appears like some sort of issue with horizon only. I wanted to get the resized cluster operating successfully before I replied, but though it re-deployed the missing node, the cluster resize went timed out and failed. Aside from a quick 30 min investigation on this I've not been able to do much more with that and it's been abandoned. Thanks all the same for your help. Tony Pearce On Thu, 12 Aug 2021 at 05:06, feilong wrote: > 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. > > ------------------------------------------------------------------------------ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Thu Sep 2 07:42:18 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Thu, 2 Sep 2021 09:42:18 +0200 Subject: [Ironic] No weekly meeting on Sep 06 Message-ID: Hello Ironicers! During our weekly meeting this week (Aug 30) we decided to skip our next weekly meeting since it is a holiday in the US -- *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 mdulko at redhat.com Thu Sep 2 08:21:14 2021 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Thu, 02 Sep 2021 10:21:14 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On Wed, 2021-09-01 at 19:28 +0200, Radosław Piliszek wrote: > On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: > > > > Hi Michal, > > > > Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. > > > > I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. > > > > Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. > > > > Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. > > We actually *do* test Kuryr in CI - in the Zun scenario - and it > works, at least on CentOS, it fails on Ubuntu for some reason but we > don't have anyone to take care of that... > Zun works using the on-host Docker as you want to do. I had a feeling that Zun is using kuryr-libnetwork, which is a different thing than kuryr itself. If the question if about kuryr- libnetwork, then it's maintained better and Hongbin Lu is an expert to try contacting with. Ping us on #openstack-kuryr and we'll try to get you his whereabouts. > *But* as Michał Dulko (hah, had to add the surname to differentiate > ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, > a similar statement applies to Zun... > Your mileage may vary but going forward I advise you take the time to > learn Kubernetes. > As for mixing up Docker Swarm with Kolla Ansible, that's not really > supported either. Kolla Ansible is designed to deploy to a bunch of > standalone Docker daemons using only host networking. > It could work but it's not tested. > > -yoctozepto > > > > > Kind regards, > > > > Paolo > > > > > > On 01/09/2021 15:57, Michał Nasiadka wrote: > > > > Hi Paolo, > > > > Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? > > I would propose the latter. > > > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. > > > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. > > > > Best regards, > > > > Michal > > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > > > 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 > From radoslaw.piliszek at gmail.com Thu Sep 2 08:39:52 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 2 Sep 2021 10:39:52 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On Thu, Sep 2, 2021 at 10:21 AM Michał Dulko wrote: > > On Wed, 2021-09-01 at 19:28 +0200, Radosław Piliszek wrote: > > On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: > > > > > > Hi Michal, > > > > > > Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. > > > > > > I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. > > > > > > Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. > > > > > > Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. > > > > We actually *do* test Kuryr in CI - in the Zun scenario - and it > > works, at least on CentOS, it fails on Ubuntu for some reason but we > > don't have anyone to take care of that... > > Zun works using the on-host Docker as you want to do. > > I had a feeling that Zun is using kuryr-libnetwork, which is a > different thing than kuryr itself. If the question if about kuryr- > libnetwork, then it's maintained better and Hongbin Lu is an expert to > try contacting with. Ping us on #openstack-kuryr and we'll try to get > you his whereabouts. Ah, yeah. In Kolla we say "kuryr" but mean "kuryr-libnetwork". We actually install both kuryr and kuryr-libnetwork in the container and run kuryr-server. Perhaps mistakenly? I see you also have kuryr-lib for common code. The Kuryr integration was contributed by none of the current Kolla folks so we might not understand the relationships well... We will gladly accept improvements there. -yoctozepto > > *But* as Michał Dulko (hah, had to add the surname to differentiate > > ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, > > a similar statement applies to Zun... > > Your mileage may vary but going forward I advise you take the time to > > learn Kubernetes. > > As for mixing up Docker Swarm with Kolla Ansible, that's not really > > supported either. Kolla Ansible is designed to deploy to a bunch of > > standalone Docker daemons using only host networking. > > It could work but it's not tested. > > > > -yoctozepto > > > > > > > > Kind regards, > > > > > > Paolo > > > > > > > > > On 01/09/2021 15:57, Michał Nasiadka wrote: > > > > > > Hi Paolo, > > > > > > Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? > > > I would propose the latter. > > > > > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. > > > > > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. > > > > > > Best regards, > > > > > > Michal > > > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > > > > > 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 > > > > > From mdulko at redhat.com Thu Sep 2 08:58:01 2021 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Thu, 02 Sep 2021 10:58:01 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On Thu, 2021-09-02 at 10:39 +0200, Radosław Piliszek wrote: > On Thu, Sep 2, 2021 at 10:21 AM Michał Dulko wrote: > > > > On Wed, 2021-09-01 at 19:28 +0200, Radosław Piliszek wrote: > > > On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: > > > > > > > > Hi Michal, > > > > > > > > Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. > > > > > > > > I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. > > > > > > > > Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. > > > > > > > > Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. > > > > > > We actually *do* test Kuryr in CI - in the Zun scenario - and it > > > works, at least on CentOS, it fails on Ubuntu for some reason but we > > > don't have anyone to take care of that... > > > Zun works using the on-host Docker as you want to do. > > > > I had a feeling that Zun is using kuryr-libnetwork, which is a > > different thing than kuryr itself. If the question if about kuryr- > > libnetwork, then it's maintained better and Hongbin Lu is an expert to > > try contacting with. Ping us on #openstack-kuryr and we'll try to get > > you his whereabouts. > > Ah, yeah. In Kolla we say "kuryr" but mean "kuryr-libnetwork". > We actually install both kuryr and kuryr-libnetwork in the container > and run kuryr-server. > Perhaps mistakenly? I see you also have kuryr-lib for common code. > The Kuryr integration was contributed by none of the current Kolla > folks so we might not understand the relationships well... > We will gladly accept improvements there. Yeah, it took me a while to get the relationships. :/ Here's how it works: * openstack/kuryr - Docker legacy network plugin *and* kuryr-lib source. * openstack/kuryr-libnetwork - Docker libnetwork implementation. * openstack/kuryr-kubernetes - (CNCF) CNI implementation, to be used in K8s. > -yoctozepto > > > > *But* as Michał Dulko (hah, had to add the surname to differentiate > > > ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, > > > a similar statement applies to Zun... > > > Your mileage may vary but going forward I advise you take the time to > > > learn Kubernetes. > > > As for mixing up Docker Swarm with Kolla Ansible, that's not really > > > supported either. Kolla Ansible is designed to deploy to a bunch of > > > standalone Docker daemons using only host networking. > > > It could work but it's not tested. > > > > > > -yoctozepto > > > > > > > > > > > Kind regards, > > > > > > > > Paolo > > > > > > > > > > > > On 01/09/2021 15:57, Michał Nasiadka wrote: > > > > > > > > Hi Paolo, > > > > > > > > Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? > > > > I would propose the latter. > > > > > > > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. > > > > > > > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. > > > > > > > > Best regards, > > > > > > > > Michal > > > > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > > > > > > > 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 > > > > > > > > > > From ricolin at ricolky.com Thu Sep 2 09:05:27 2021 From: ricolin at ricolky.com (Rico Lin) Date: Thu, 2 Sep 2021 17:05:27 +0800 Subject: [tc][all]Please help to identify common pain points & video meeting scheduled next week In-Reply-To: References: Message-ID: Dear all For this pain point targeting, we will have this topic discussion in TC meeting today, Sept 2nd at 1500 UTC. Please join if you're interested. It will be a video call on google meet. See here for more details: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer at EasyStack On Fri, Aug 27, 2021 at 8:16 PM Rico Lin wrote: > 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 radoslaw.piliszek at gmail.com Thu Sep 2 09:30:10 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 2 Sep 2021 11:30:10 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On Thu, Sep 2, 2021 at 10:58 AM Michał Dulko wrote: > > On Thu, 2021-09-02 at 10:39 +0200, Radosław Piliszek wrote: > > On Thu, Sep 2, 2021 at 10:21 AM Michał Dulko wrote: > > > > > > On Wed, 2021-09-01 at 19:28 +0200, Radosław Piliszek wrote: > > > > On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: > > > > > > > > > > Hi Michal, > > > > > > > > > > Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. > > > > > > > > > > I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. > > > > > > > > > > Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. > > > > > > > > > > Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. > > > > > > > > We actually *do* test Kuryr in CI - in the Zun scenario - and it > > > > works, at least on CentOS, it fails on Ubuntu for some reason but we > > > > don't have anyone to take care of that... > > > > Zun works using the on-host Docker as you want to do. > > > > > > I had a feeling that Zun is using kuryr-libnetwork, which is a > > > different thing than kuryr itself. If the question if about kuryr- > > > libnetwork, then it's maintained better and Hongbin Lu is an expert to > > > try contacting with. Ping us on #openstack-kuryr and we'll try to get > > > you his whereabouts. > > > > Ah, yeah. In Kolla we say "kuryr" but mean "kuryr-libnetwork". > > We actually install both kuryr and kuryr-libnetwork in the container > > and run kuryr-server. > > Perhaps mistakenly? I see you also have kuryr-lib for common code. > > The Kuryr integration was contributed by none of the current Kolla > > folks so we might not understand the relationships well... > > We will gladly accept improvements there. > > Yeah, it took me a while to get the relationships. :/ Here's how it > works: > > * openstack/kuryr - Docker legacy network plugin *and* kuryr-lib > source. > * openstack/kuryr-libnetwork - Docker libnetwork implementation. > * openstack/kuryr-kubernetes - (CNCF) CNI implementation, to be used > in K8s. Thank you! It seems we are doing the right thing then. ;-) -yoctozepto > > -yoctozepto > > > > > > *But* as Michał Dulko (hah, had to add the surname to differentiate > > > > ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, > > > > a similar statement applies to Zun... > > > > Your mileage may vary but going forward I advise you take the time to > > > > learn Kubernetes. > > > > As for mixing up Docker Swarm with Kolla Ansible, that's not really > > > > supported either. Kolla Ansible is designed to deploy to a bunch of > > > > standalone Docker daemons using only host networking. > > > > It could work but it's not tested. > > > > > > > > -yoctozepto > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > Paolo > > > > > > > > > > > > > > > On 01/09/2021 15:57, Michał Nasiadka wrote: > > > > > > > > > > Hi Paolo, > > > > > > > > > > Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? > > > > > I would propose the latter. > > > > > > > > > > About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. > > > > > > > > > > Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. > > > > > > > > > > Best regards, > > > > > > > > > > Michal > > > > > On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > From skaplons at redhat.com Thu Sep 2 10:52:40 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 02 Sep 2021 12:52:40 +0200 Subject: [neutron] Drivers meeting - Friday 3.09.2021 - cancelled Message-ID: <5137718.HvKhCC5Nb5@p1> Hi, Due to lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. -- 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 zigo at debian.org Thu Sep 2 11:25:49 2021 From: zigo at debian.org (Thomas Goirand) Date: Thu, 2 Sep 2021 13:25:49 +0200 Subject: [nova][cinder][barbican] storing secrets in service project In-Reply-To: <8ef51d37977fb2cd2d37fa6ccc69fa7864032598.camel@redhat.com> References: <8ef51d37977fb2cd2d37fa6ccc69fa7864032598.camel@redhat.com> Message-ID: <87057647-a349-082c-62a6-8f9b92f7319f@debian.org> On 8/31/21 4:17 PM, Sean Mooney wrote: > 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. access the secret != delete a secret ... >> 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. It's perfectly legitimate for an admin to delete *ANY* resource if he feels he needs to. For example on a public cloud: after the grace period expired. Example for an internal cloud: when an employee leaves. >> 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. It is a bug that we can't live-migrate LUKS volumes. Please do recognize this as an OpenStack defect, because if you don't, you wont recognize we need to fix the situation, which is kind of super bad. >> 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. We you can't start the VM, it means you can't live-migrate. So there's a big issue to tackle here. I don't agree that it's a big issue that an admin can access secrets, because it's already the case (ie: by adding the creator role in that project). If you don't trust your admin: go away, it's game over anyways. As for LUKS devices, it'd be trivial for an admin to dump the VM's memory and access the decryption key anyways... So you're only being annoying to the admins, and not protecting anyone here. Cheers, Thomas Goirand (zigo) From smooney at redhat.com Thu Sep 2 11:45:39 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 02 Sep 2021 12:45:39 +0100 Subject: [nova][cinder][barbican] storing secrets in service project In-Reply-To: <87057647-a349-082c-62a6-8f9b92f7319f@debian.org> References: <8ef51d37977fb2cd2d37fa6ccc69fa7864032598.camel@redhat.com> <87057647-a349-082c-62a6-8f9b92f7319f@debian.org> Message-ID: On Thu, 2021-09-02 at 13:25 +0200, Thomas Goirand wrote: > On 8/31/21 4:17 PM, Sean Mooney wrote: > > 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. > > access the secret != delete a secret ... > > > > 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. > > It's perfectly legitimate for an admin to delete *ANY* resource if he > feels he needs to. For example on a public cloud: after the grace period > expired. Example for an internal cloud: when an employee leaves. > > > > 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. > > It is a bug that we can't live-migrate LUKS volumes. Please do recognize > this as an OpenStack defect, because if you don't, you wont recognize we > need to fix the situation, which is kind of super bad. live-migration should actully work i belive for ceph. i think its just if the volume is host mounted like we do with isci that it fails. cold migration will partly work you just wont be able to start the instance so you can cold migrate a shut off instance. same for evacuate. > > > > 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. > > We you can't start the VM, it means you can't live-migrate. > sure but if its not running you can cold migrate it. > So there's a > big issue to tackle here. > not really you should not be starting the instance in this case. if its off you should just cold migrate. that work in more cases the live migrate and is more effcinet since we wont have to copy any guest memory. > I don't agree that it's a big issue that an > admin can access secrets, because it's already the case (ie: by adding > the creator role in that project).  > > If you don't trust your admin: go > away, it's game over anyways. > this is hte how point of secure comptueing and the sev/image incryption work that peopel have been tryign to add to nova. the ablity to upload encypted images and use them to create encypted volumes that the admin cant access which can be verifyed using vtpm and other methods is becoming more and more a requirement for many government customers. > As for LUKS devices, it'd be trivial for > an admin to dump the VM's memory and access the decryption key > anyways... So you're only being annoying to the admins, and not > protecting anyone here. this is why SEV support was intoduced to prevent admin form doing that. its not about being annoying to admins its about ensureing we can actuly use openstack in secure enviroment so that we can continue to support our customer that need a miniuma or zero trust solution. > > Cheers, > > Thomas Goirand (zigo) > From paolo at celati.com Thu Sep 2 12:20:26 2021 From: paolo at celati.com (Paolo Celati) Date: Thu, 2 Sep 2021 14:20:26 +0200 Subject: [kolla-ansible] [kuryr] Running Docker Swarm with Kuryr networking In-Reply-To: References: <7132cbfa-c8be-76c7-3f77-5027f74eff2e@celati.com> Message-ID: On 01/09/2021 19:28, Radosław Piliszek wrote: > On Wed, Sep 1, 2021 at 6:08 PM Paolo Celati wrote: >> >> Hi Michal, >> >> Yes I would rather run all my Docker containers on the physical hosts. At the moment I run Ceph and kolla images, but adding Swarm as well would be useful. >> >> I've had a fair number of problems with Magnum because it appears only Kubernetes is supported nowadays, and I have 0 experience with that. I also prefer Swarm because it's a lot simpler for small scale. >> >> Administering my own VMs with Docker Swarm on top is also not exactly the best solution because that introduces extra machines to maintain. And I don't have lots of spare RAM either as it's a homelab. >> >> Thanks for reminding me about tagging correctly, I forgot to put [kuryr]. Ok didn't know about the lack of CI but good to know. > > We actually *do* test Kuryr in CI - in the Zun scenario - and it > works, at least on CentOS, it fails on Ubuntu for some reason but we > don't have anyone to take care of that... > Zun works using the on-host Docker as you want to do. > *But* as Michał Dulko (hah, had to add the surname to differentiate > ;-) ) said non-Kubernetes Kuryr is largely unmaintained and, actually, > a similar statement applies to Zun... > Your mileage may vary but going forward I advise you take the time to > learn Kubernetes. > As for mixing up Docker Swarm with Kolla Ansible, that's not really > supported either. Kolla Ansible is designed to deploy to a bunch of > standalone Docker daemons using only host networking. > It could work but it's not tested. > > -yoctozepto > Hi Radoslaw, Ok thanks I'll look into Kubernetes then, it looks like everything is going in that direction anyways so might as well. Well what I was intending to do with Docker Swarm is really just share the hosts running Kolla containers and Swarm containers. It makes for a lot less management work to have fewer Docker daemons. My idea was to have Kolla containers use host networking and Swarm uses overlay (vxlan) networks via Kuryr. But I'll probably try getting Magnum + Kubernetes up instead since that seems the best supported scenario. Paolo >> >> Kind regards, >> >> Paolo >> >> >> On 01/09/2021 15:57, Michał Nasiadka wrote: >> >> Hi Paolo, >> >> Would you like to use the Docker engine that is running on the OpenStack cluster hosts, or create Virtual Machines that will be used for a Docker Swarm cluster? >> I would propose the latter. >> >> About Kuryr - we don’t have CI coverage for testing Kuryr in Kolla-Ansible deployment, so the container images and Ansible deployment role are provided as-is currently. >> >> Maybe somebody from Kuryr project could help you out? Adding [kuryr] tag for visibility. >> >> Best regards, >> >> Michal >> On 1 Sep 2021, 00:32 +0200, Paolo Celati , wrote: >> >> 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 -------------- 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 micou12 at gmail.com Thu Sep 2 13:33:05 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Thu, 2 Sep 2021 15:33:05 +0200 Subject: Fwd: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: ---------- Forwarded message --------- From: Michel Niyoyita Date: Thu, Sep 2, 2021 at 12:17 PM Subject: Fwd: [ceph-users] Re: Replacing swift with RGW To: ---------- Forwarded message --------- From: Eugen Block Date: Thu, Sep 2, 2021 at 10:39 AM Subject: Re: [ceph-users] Re: Replacing swift with RGW To: Michel Niyoyita You should continue this thread on the openstack-discuss mailing list (openstack-discuss at lists.openstack.org) since this is not a ceph issue. I'm not familiar with kolla and I don't know the requirements to install openstack-swift, you'll need to ask the openstack community. Zitat von Michel Niyoyita : > Below are errors I am getting once I try to run swift commands . the second > one is the error I get once try to install python-swiftclient > > (kolla-open) [stack at kolla-open ~]$ swift -v stat > -bash: swift: command not found > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install python-swiftclient > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 AM > CAT. > No match for argument: python-swiftclient > Error: Unable to find a match: python-swiftclient > (kolla-open) [stack at kolla-open ~]$ > > Waiting for your help > > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: > >> I can't tell for sure, but yes, I believe you need the openstack-swift >> package (with dependencies). What errors do you get? The more >> information you share the better people can help. >> >> >> Zitat von Michel Niyoyita : >> >> > I tried to install "sudo yum -y install python-swiftclient" on openstack >> > side but fails . are there openastack-shwift packages which are needed? >> > if are there please help me to get . may be also it is the cause I am >> > failing to run swift command on openstack cli side. >> > >> > thank you for your continued support. >> > >> > Micheal >> > >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >> > >> >> I only configured the endpoints for the clients to directly access the >> >> RGWs, but you'll probably need to install the openstack-swift package. >> >> Or have you done that already? >> >> >> >> >> >> Zitat von Michel Niyoyita : >> >> >> >> > Thank you Eugen for your prompt response. >> >> > >> >> > Now the commands provided work. but I am not finding the object >> storage >> >> on >> >> > the horizon dashboard , but it appears in the system information >> >> services. >> >> > [image: image.png] >> >> > so my question is how to configure it in order that it can appear in >> the >> >> > dashboard . >> >> > >> >> > Michel >> >> > >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block wrote: >> >> > >> >> >> Sorry, one little detail slipped through, the '--region' flag has to >> >> >> be put before the 'service' name. The correct command would be: >> >> >> >> >> >> openstack endpoint create --region RegionOne swift admin >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> >> >> and respectively for the other interfaces. >> >> >> >> >> >> >> >> >> Zitat von Eugen Block : >> >> >> >> >> >> > Hi, >> >> >> > >> >> >> > this is not a ceph issue but your openstack cli command as the >> error >> >> >> > message states. >> >> >> > >> >> >> > Try one interface at a time: >> >> >> > >> >> >> > openstack endpoint create swift public >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> > openstack endpoint create swift admin >> http://ceph-osd3:8080/swift/v1 >> >> >> > --region RegionOne swift >> >> >> > openstack endpoint create swift internal >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> > >> >> >> > >> >> >> > Zitat von Michel Niyoyita : >> >> >> > >> >> >> >> Hello , >> >> >> >> >> >> >> >> Below are errors I am getting once I am trying to integrate swift >> >> with >> >> >> >> Radosgateway. >> >> >> >> >> >> >> >> From openstack side once i try to endpoint which will point to the >> >> >> >> radosgateway : >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint create >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> --region RegionOne swift >> >> >> >> usage: openstack endpoint create [-h] [-f >> >> {json,shell,table,value,yaml}] >> >> >> >> [-c COLUMN] [--noindent] [--prefix >> >> >> PREFIX] >> >> >> >> [--max-width ] >> [--fit-width] >> >> >> >> [--print-empty] [--region >> >> ] >> >> >> >> [--enable | --disable] >> >> >> >> >> >> >> >> openstack endpoint create: error: argument : invalid >> >> choice: >> >> >> ' >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', 'public', >> >> >> 'internal') >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >> >> >> >> >> >> >> >> below are my /etc/ceph/ceph.conf file : >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3] >> >> >> >> rgw_dns_name = ceph-osd3 >> >> >> >> host = ceph-osd3 >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 num_threads=100 >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >> >> >> >> rgw_keystone_admin_user=admin >> >> >> >> rgw_keystone_admin_password=admin >> >> >> >> rgw_keystone_admin_tenant=admin >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >> >> >> >> rgw_keystone_token_cache_size=200 >> >> >> >> rgw_keystone_revocation_interval=300 >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >> >> >> >> host = ceph-osd3 >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >> >> >> >> rgw thread pool size = 512 >> >> >> >> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with 10.10.29.110 as >> IP >> >> >> >> >> >> >> >> and 10.10.29.150 all-in-one IP >> >> >> >> >> >> >> >> >> >> >> >> Please crosscheck where I might make mistake and try to correct. >> >> >> >> >> >> >> >> Best regards >> >> >> >> >> >> >> >> Michel >> >> >> >> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >> >> >> etienne.menguy at croit.io> >> >> >> >> wrote: >> >> >> >> >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> There are some information on Ceph documentation >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >> >> >> >>> - Use keystone as auth for RGW >> >> >> >>> - Create service and register your RGW as swift >> >> >> >>> >> >> >> >>> Étienne >> >> >> >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita >> >> wrote: >> >> >> >>>> >> >> >> >>>> Hello , >> >> >> >>>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using ceph >> >> ansible >> >> >> and >> >> >> >>>> create sub user to access the created containers and would like >> to >> >> >> >>> replace >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >> >> configuration >> >> >> to >> >> >> >>> be >> >> >> >>>> done in the OpenStack side in order to integrate those >> services. I >> >> >> have >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu 20.04. >> and >> >> >> ceph >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >> >> >> >>>> >> >> >> >>>> Kindly help for the configuration or documentation. >> >> >> >>>> >> >> >> >>>> Best Regards >> >> >> >>>> >> >> >> >>>> Michel >> >> >> >>>> _______________________________________________ >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >>> >> >> >> >> _______________________________________________ >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaitcev at redhat.com Thu Sep 2 14:21:44 2021 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 2 Sep 2021 09:21:44 -0500 Subject: [Swift][Interop] PTG time In-Reply-To: References: Message-ID: <20210902092144.1a44225f@suzdal.zaitcev.lan> On Fri, 6 Aug 2021 11:32:22 -0500 Arkady Kanevsky wrote: > Interop team would like time on Yoga PTG Monday or Tu between 21-22 UTC > to discuss Interop guideline coverage for Swift. I suspect this fell through the cracks, it's not on Swift PTG Etherpad. I'll poke our PTL. The slots you're proposing aren't in conflict with existing PTG schedule, so this should work. -- Pete From aschultz at redhat.com Thu Sep 2 14:27:28 2021 From: aschultz at redhat.com (Alex Schultz) Date: Thu, 2 Sep 2021 08:27:28 -0600 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: The swift docs are a bit out of date as they still reference python2 despite python3 being supported for some time now. Replace python- with python3- and try again. On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita wrote: > > > ---------- Forwarded message --------- > From: Michel Niyoyita > Date: Thu, Sep 2, 2021 at 12:17 PM > Subject: Fwd: [ceph-users] Re: Replacing swift with RGW > To: > > > > > ---------- Forwarded message --------- > From: Eugen Block > Date: Thu, Sep 2, 2021 at 10:39 AM > Subject: Re: [ceph-users] Re: Replacing swift with RGW > To: Michel Niyoyita > > > You should continue this thread on the openstack-discuss mailing list > (openstack-discuss at lists.openstack.org) since this is not a ceph issue. > I'm not familiar with kolla and I don't know the requirements to > install openstack-swift, you'll need to ask the openstack community. > > > Zitat von Michel Niyoyita : > > > Below are errors I am getting once I try to run swift commands . the > second > > one is the error I get once try to install python-swiftclient > > > > (kolla-open) [stack at kolla-open ~]$ swift -v stat > > -bash: swift: command not found > > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install > python-swiftclient > > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 > AM > > CAT. > > No match for argument: python-swiftclient > > Error: Unable to find a match: python-swiftclient > > (kolla-open) [stack at kolla-open ~]$ > > > > Waiting for your help > > > > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: > > > >> I can't tell for sure, but yes, I believe you need the openstack-swift > >> package (with dependencies). What errors do you get? The more > >> information you share the better people can help. > >> > >> > >> Zitat von Michel Niyoyita : > >> > >> > I tried to install "sudo yum -y install python-swiftclient" on > openstack > >> > side but fails . are there openastack-shwift packages which are > needed? > >> > if are there please help me to get . may be also it is the cause I am > >> > failing to run swift command on openstack cli side. > >> > > >> > thank you for your continued support. > >> > > >> > Micheal > >> > > >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: > >> > > >> >> I only configured the endpoints for the clients to directly access > the > >> >> RGWs, but you'll probably need to install the openstack-swift > package. > >> >> Or have you done that already? > >> >> > >> >> > >> >> Zitat von Michel Niyoyita : > >> >> > >> >> > Thank you Eugen for your prompt response. > >> >> > > >> >> > Now the commands provided work. but I am not finding the object > >> storage > >> >> on > >> >> > the horizon dashboard , but it appears in the system information > >> >> services. > >> >> > [image: image.png] > >> >> > so my question is how to configure it in order that it can appear > in > >> the > >> >> > dashboard . > >> >> > > >> >> > Michel > >> >> > > >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block wrote: > >> >> > > >> >> >> Sorry, one little detail slipped through, the '--region' flag has > to > >> >> >> be put before the 'service' name. The correct command would be: > >> >> >> > >> >> >> openstack endpoint create --region RegionOne swift admin > >> >> >> http://ceph-osd3:8080/swift/v1 > >> >> >> > >> >> >> and respectively for the other interfaces. > >> >> >> > >> >> >> > >> >> >> Zitat von Eugen Block : > >> >> >> > >> >> >> > Hi, > >> >> >> > > >> >> >> > this is not a ceph issue but your openstack cli command as the > >> error > >> >> >> > message states. > >> >> >> > > >> >> >> > Try one interface at a time: > >> >> >> > > >> >> >> > openstack endpoint create swift public > >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift > >> >> >> > openstack endpoint create swift admin > >> http://ceph-osd3:8080/swift/v1 > >> >> >> > --region RegionOne swift > >> >> >> > openstack endpoint create swift internal > >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift > >> >> >> > > >> >> >> > > >> >> >> > Zitat von Michel Niyoyita : > >> >> >> > > >> >> >> >> Hello , > >> >> >> >> > >> >> >> >> Below are errors I am getting once I am trying to integrate > swift > >> >> with > >> >> >> >> Radosgateway. > >> >> >> >> > >> >> >> >> From openstack side once i try to endpoint which will point to > the > >> >> >> >> radosgateway : > >> >> >> >> > >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint > create > >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl > >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal > >> >> >> http://ceph-osd3:8080/swift/v1 > >> >> >> >> --region RegionOne swift > >> >> >> >> usage: openstack endpoint create [-h] [-f > >> >> {json,shell,table,value,yaml}] > >> >> >> >> [-c COLUMN] [--noindent] > [--prefix > >> >> >> PREFIX] > >> >> >> >> [--max-width ] > >> [--fit-width] > >> >> >> >> [--print-empty] [--region > >> >> ] > >> >> >> >> [--enable | --disable] > >> >> >> >> > >> >> >> >> openstack endpoint create: error: argument : invalid > >> >> choice: > >> >> >> ' > >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', > 'public', > >> >> >> 'internal') > >> >> >> >> > >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ > >> >> >> >> > >> >> >> >> below are my /etc/ceph/ceph.conf file : > >> >> >> >> > >> >> >> >> [client.rgw.ceph-osd3] > >> >> >> >> rgw_dns_name = ceph-osd3 > >> >> >> >> host = ceph-osd3 > >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring > >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log > >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 > num_threads=100 > >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 > >> >> >> >> rgw_keystone_admin_user=admin > >> >> >> >> rgw_keystone_admin_password=admin > >> >> >> >> rgw_keystone_admin_tenant=admin > >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator > >> >> >> >> rgw_keystone_token_cache_size=200 > >> >> >> >> rgw_keystone_revocation_interval=300 > >> >> >> >> > >> >> >> >> [client.rgw.ceph-osd3.rgw0] > >> >> >> >> host = ceph-osd3 > >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring > >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log > >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 > >> >> >> >> rgw thread pool size = 512 > >> >> >> >> > >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with 10.10.29.110 > as > >> IP > >> >> >> >> > >> >> >> >> and 10.10.29.150 all-in-one IP > >> >> >> >> > >> >> >> >> > >> >> >> >> Please crosscheck where I might make mistake and try to > correct. > >> >> >> >> > >> >> >> >> Best regards > >> >> >> >> > >> >> >> >> Michel > >> >> >> >> > >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < > >> >> >> etienne.menguy at croit.io> > >> >> >> >> wrote: > >> >> >> >> > >> >> >> >>> Hi, > >> >> >> >>> > >> >> >> >>> There are some information on Ceph documentation > >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < > >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . > >> >> >> >>> - Use keystone as auth for RGW > >> >> >> >>> - Create service and register your RGW as swift > >> >> >> >>> > >> >> >> >>> Étienne > >> >> >> >>> > >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita > > >> >> wrote: > >> >> >> >>>> > >> >> >> >>>> Hello , > >> >> >> >>>> > >> >> >> >>>> I have configured RGW in my ceph cluster deployed using ceph > >> >> ansible > >> >> >> and > >> >> >> >>>> create sub user to access the created containers and would > like > >> to > >> >> >> >>> replace > >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on > >> >> configuration > >> >> >> to > >> >> >> >>> be > >> >> >> >>>> done in the OpenStack side in order to integrate those > >> services. I > >> >> >> have > >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu > 20.04. > >> and > >> >> >> ceph > >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 > >> >> >> >>>> > >> >> >> >>>> Kindly help for the configuration or documentation. > >> >> >> >>>> > >> >> >> >>>> Best Regards > >> >> >> >>>> > >> >> >> >>>> Michel > >> >> >> >>>> _______________________________________________ > >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io > >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io > >> >> >> >>> > >> >> >> >>> _______________________________________________ > >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io > >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io > >> >> >> >>> > >> >> >> >> _______________________________________________ > >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io > >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io > >> >> >> > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> ceph-users mailing list -- ceph-users at ceph.io > >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akanevsk at redhat.com Thu Sep 2 15:13:20 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Thu, 2 Sep 2021 10:13:20 -0500 Subject: [Swift][Interop] PTG time In-Reply-To: <20210902092144.1a44225f@suzdal.zaitcev.lan> References: <20210902092144.1a44225f@suzdal.zaitcev.lan> Message-ID: Thanks Pete. On Thu, Sep 2, 2021 at 9:21 AM Pete Zaitcev wrote: > On Fri, 6 Aug 2021 11:32:22 -0500 > Arkady Kanevsky wrote: > > > Interop team would like time on Yoga PTG Monday or Tu between 21-22 UTC > > to discuss Interop guideline coverage for Swift. > > I suspect this fell through the cracks, it's not on Swift PTG Etherpad. > I'll poke our PTL. The slots you're proposing aren't in conflict with > existing PTG schedule, so this should work. > > -- Pete > > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.Kieske at mittwald.de Thu Sep 2 16:48:32 2021 From: S.Kieske at mittwald.de (Sven Kieske) Date: Thu, 2 Sep 2021 16:48:32 +0000 Subject: [nova]is there support for discard/trim in virtio-blk? Message-ID: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> Hi, according to our research discard/trim is commonly documented as "not supported by virtio-blk" in the wider community and in openstack nova[0]. I understand that this was not supported by the kernel or qemu when discard support was initially implemented[1] in openstack, but times have changed. Virtio-blk in upstream Kernel[2] and in qemu[3] does clearly support discard/trim, which we discovered thanks to StackExchange[4]. So my question is, has someone successfully used trim/discard with virtio-blk in nova provisioned vms? [1] makes me guess, that there is no codepath that works with virtio-blk, but I'm not sure I understood all the codepaths in nova yet. we are still working our way through it, though. We currently use the train release in conjunction with ceph rbd volumes for testing this feature but weren't yet able to use it successfully. Looking at nova's master branch not much seems to have changed regarding trim support. If this is no supported configuration currently, should I submit a blueprint to enable this feature? Would there be other devs/ops interested in this? Any help or pointers would be appreciated. [0]: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2015 (nova debug log saying discard is unsupported for virtio) [1]: https://blueprints.launchpad.net/nova/+spec/cinder-backend-report-discard (initial implementation of discard support in openstack) [2]: https://github.com/torvalds/linux/commit/1f23816b8eb8fdc39990abe166c10a18c16f6b21 (available since linux 5.0-rc1) [3]: https://github.com/qemu/qemu/commit/37b06f8d46fe602e630e4bdce24e80a3e0f70cc2 (available since qemu 4.0.0) [4]: https://unix.stackexchange.com/a/518223 -- 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 smooney at redhat.com Thu Sep 2 17:44:42 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 02 Sep 2021 18:44:42 +0100 Subject: [nova]is there support for discard/trim in virtio-blk? In-Reply-To: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> References: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> Message-ID: <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> On Thu, 2021-09-02 at 16:48 +0000, Sven Kieske wrote: > Hi, > > according to our research discard/trim is commonly documented as "not supported by virtio-blk" > in the wider community and in openstack nova[0]. > > I understand that this was not supported by the kernel or qemu when discard support was > initially implemented[1] in openstack, but times have changed. > > Virtio-blk in upstream Kernel[2] and in qemu[3] does clearly support > discard/trim, which we discovered thanks to StackExchange[4]. > > So my question is, has someone successfully used trim/discard with > virtio-blk in nova provisioned vms? that is a good question. if it works in upstrema qemu it should work with a nova provisioned vm unless there is something we explitly need to add in teh xml to make it work. i suspect it will jsut work and we > > [1] makes me guess, that there is no codepath that works with > virtio-blk, but I'm not sure I understood all the codepaths in nova yet. > we are still working our way through it, though. virtio-blk is our default storage backend for libvirt. if you dont specifiy otherwise its using virtio-blk, to request it explcitly you set hw_disk_bus=virtio virtio in the image properties mappes to virtio-blk, if you want virtio-scsi you have to request that explictly. > > We currently use the train release in conjunction with ceph rbd volumes for testing this feature > but weren't yet able to use it successfully. > Looking at nova's master branch not much seems to have changed regarding trim support. in the past to use trim you had to configure virtio-scsi in the past so that was the supported way to enable this when train was released. looking at libcvirt we might need to pas som addtional optional driver argument to make it work https://libvirt.org/formatdomain.html The optional discard attribute controls whether discard requests (also known as "trim" or "unmap") are ignored or passed to the filesystem. The value can be either "unmap" (allow the discard request to be passed) or "ignore" (ignore the discard request). Since 1.0.6 (QEMU and KVM only) The optional detect_zeroes attribute controls whether to detect zero write requests. The value can be "off", "on" or "unmap". First two values turn the detection off and on, respectively. The third value ("unmap") turns the detection on and additionally tries to discard such areas from the image based on the value of discard above (it will act as "on" if discard is set to "ignore"). NB enabling the detection is a compute intensive operation, but can save file space and/or time on slow media. Since 2.0.0 although its not clear that libvirt was updated to support the virtio-blk support added in qemu 4.0.0 sicne the libvirt docs were not updated to refernce that. > > If this is no supported configuration currently, should I submit a blueprint to enable this feature? yes although i think we need to confirm if this is support in libvirt kasyap perhaps you could ask our virt folk interneally and find out if we need to do anythin to enable trim support for virtio-blk? we do have support for seting the driver discard option https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/config.py#L1058 and there is an nova config option to enable it. https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_disk_discard so perhaps you just need to set that o unmap e.g. /etc/nova/nova.conf: [libvirt] hw_disk_discard=unmap it is used in teh images backend https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/imagebackend.py#L104 and we also seam to have support in the volume driver https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/volume/volume.py#L94-L96 so i suspect you are just missing setting the config option to unmap and the debug log in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2015 is proably outdated and can be removed if yoiu can validate the config option works then can you open a bug for the outdated message? > > Would there be other devs/ops interested in this? > > Any help or pointers would be appreciated. > > [0]: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2015 (nova debug log saying discard is unsupported for virtio) > [1]: https://blueprints.launchpad.net/nova/+spec/cinder-backend-report-discard (initial implementation of discard support in openstack) > [2]: https://github.com/torvalds/linux/commit/1f23816b8eb8fdc39990abe166c10a18c16f6b21 (available since linux 5.0-rc1) > [3]: https://github.com/qemu/qemu/commit/37b06f8d46fe602e630e4bdce24e80a3e0f70cc2 (available since qemu 4.0.0) > [4]: https://unix.stackexchange.com/a/518223 > From zhangbailin at inspur.com Thu Sep 2 01:50:17 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Thu, 2 Sep 2021 01:50:17 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1SZTogW2FsbF1b?= =?utf-8?B?dGNdIFRlY2huaWNhbCBDb21taXR0ZWUgbmV4dCB3ZWVrbHkgbWVldGluZyBv?= =?utf-8?Q?n_Sept_2nd_at_1500_UTC?= In-Reply-To: <17ba318be97.cc9f4e3e210522.5438255807862395887@ghanshyammann.com> References: <70ccb3ff212d51b5854e046a114f33f5@sslemail.net> <17ba318be97.cc9f4e3e210522.5438255807862395887@ghanshyammann.com> Message-ID: Hi TC team, Thanks. Hi all, regarding the venus project, if you have any questions, you can leave a comment at https://review.opendev.org/c/openstack/governance/+/804824 or through the mailing list. The attachment is the design framework and function introduction of Venus ,please check. brinzhang Inspur Electronic Information Industry Co.,Ltd. -----邮件原件----- 发件人: Ghanshyam Mann [mailto:gmann at ghanshyammann.com] 发送时间: 2021年9月2日 4:42 收件人: openstack-discuss 主题: [lists.openstack.org代发]Re: [all][tc] Technical Committee next weekly meeting on Sept 2nd at 1500 UTC Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. NOTE: Tomorrow meeting will be a Video call at google meet, joining information are present in 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/ * Leaderless projects ** https://etherpad.opendev.org/p/yoga-leaderless * New project application: 'Venus' ** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html ** https://review.opendev.org/c/openstack/governance/+/804824 * Next step on pain points from projects/SIGs/pop-up (ricolin) ** https://etherpad.opendev.org/p/pain-point-elimination * Propose OpenStack News: Newsletter ** https://etherpad.opendev.org/p/newsletter-openstack-news * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Tue, 31 Aug 2021 12:02:17 -0500 Ghanshyam Mann wrote ---- > 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: venus works for OpenStack-v1.0.pdf Type: application/pdf Size: 628025 bytes Desc: venus works for OpenStack-v1.0.pdf URL: From micou12 at gmail.com Thu Sep 2 10:16:37 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Thu, 2 Sep 2021 12:16:37 +0200 Subject: Replacing swift with RGW Message-ID: Hello , I tried to replace Swift RGW but I face some errors 1) the object storage doesnot appear to the dashboard . but it appears in systems information and also it shows the rgw where it points . [image: image.png] the second error I try to run swift command through openstack cli but fails (kolla-open) [stack at kolla-open ~]$ swift -v stat -bash: swift: command not found (kolla-open) [stack at kolla-open ~]$ sudo yum -y install python-swiftclient Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 AM CAT. No match for argument: python-swiftclient Error: Unable to find a match: python-swiftclient (kolla-open) [stack at kolla-open ~]$ . Kindly advise Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 44626 bytes Desc: not available URL: From micou12 at gmail.com Thu Sep 2 10:17:35 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Thu, 2 Sep 2021 12:17:35 +0200 Subject: Fwd: [ceph-users] Re: Replacing swift with RGW In-Reply-To: <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: ---------- Forwarded message --------- From: Eugen Block Date: Thu, Sep 2, 2021 at 10:39 AM Subject: Re: [ceph-users] Re: Replacing swift with RGW To: Michel Niyoyita You should continue this thread on the openstack-discuss mailing list (openstack-discuss at lists.openstack.org) since this is not a ceph issue. I'm not familiar with kolla and I don't know the requirements to install openstack-swift, you'll need to ask the openstack community. Zitat von Michel Niyoyita : > Below are errors I am getting once I try to run swift commands . the second > one is the error I get once try to install python-swiftclient > > (kolla-open) [stack at kolla-open ~]$ swift -v stat > -bash: swift: command not found > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install python-swiftclient > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 AM > CAT. > No match for argument: python-swiftclient > Error: Unable to find a match: python-swiftclient > (kolla-open) [stack at kolla-open ~]$ > > Waiting for your help > > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: > >> I can't tell for sure, but yes, I believe you need the openstack-swift >> package (with dependencies). What errors do you get? The more >> information you share the better people can help. >> >> >> Zitat von Michel Niyoyita : >> >> > I tried to install "sudo yum -y install python-swiftclient" on openstack >> > side but fails . are there openastack-shwift packages which are needed? >> > if are there please help me to get . may be also it is the cause I am >> > failing to run swift command on openstack cli side. >> > >> > thank you for your continued support. >> > >> > Micheal >> > >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >> > >> >> I only configured the endpoints for the clients to directly access the >> >> RGWs, but you'll probably need to install the openstack-swift package. >> >> Or have you done that already? >> >> >> >> >> >> Zitat von Michel Niyoyita : >> >> >> >> > Thank you Eugen for your prompt response. >> >> > >> >> > Now the commands provided work. but I am not finding the object >> storage >> >> on >> >> > the horizon dashboard , but it appears in the system information >> >> services. >> >> > [image: image.png] >> >> > so my question is how to configure it in order that it can appear in >> the >> >> > dashboard . >> >> > >> >> > Michel >> >> > >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block wrote: >> >> > >> >> >> Sorry, one little detail slipped through, the '--region' flag has to >> >> >> be put before the 'service' name. The correct command would be: >> >> >> >> >> >> openstack endpoint create --region RegionOne swift admin >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> >> >> and respectively for the other interfaces. >> >> >> >> >> >> >> >> >> Zitat von Eugen Block : >> >> >> >> >> >> > Hi, >> >> >> > >> >> >> > this is not a ceph issue but your openstack cli command as the >> error >> >> >> > message states. >> >> >> > >> >> >> > Try one interface at a time: >> >> >> > >> >> >> > openstack endpoint create swift public >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> > openstack endpoint create swift admin >> http://ceph-osd3:8080/swift/v1 >> >> >> > --region RegionOne swift >> >> >> > openstack endpoint create swift internal >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> > >> >> >> > >> >> >> > Zitat von Michel Niyoyita : >> >> >> > >> >> >> >> Hello , >> >> >> >> >> >> >> >> Below are errors I am getting once I am trying to integrate swift >> >> with >> >> >> >> Radosgateway. >> >> >> >> >> >> >> >> From openstack side once i try to endpoint which will point to the >> >> >> >> radosgateway : >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint create >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> --region RegionOne swift >> >> >> >> usage: openstack endpoint create [-h] [-f >> >> {json,shell,table,value,yaml}] >> >> >> >> [-c COLUMN] [--noindent] [--prefix >> >> >> PREFIX] >> >> >> >> [--max-width ] >> [--fit-width] >> >> >> >> [--print-empty] [--region >> >> ] >> >> >> >> [--enable | --disable] >> >> >> >> >> >> >> >> openstack endpoint create: error: argument : invalid >> >> choice: >> >> >> ' >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', 'public', >> >> >> 'internal') >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >> >> >> >> >> >> >> >> below are my /etc/ceph/ceph.conf file : >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3] >> >> >> >> rgw_dns_name = ceph-osd3 >> >> >> >> host = ceph-osd3 >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 num_threads=100 >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >> >> >> >> rgw_keystone_admin_user=admin >> >> >> >> rgw_keystone_admin_password=admin >> >> >> >> rgw_keystone_admin_tenant=admin >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >> >> >> >> rgw_keystone_token_cache_size=200 >> >> >> >> rgw_keystone_revocation_interval=300 >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >> >> >> >> host = ceph-osd3 >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >> >> >> >> rgw thread pool size = 512 >> >> >> >> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with 10.10.29.110 as >> IP >> >> >> >> >> >> >> >> and 10.10.29.150 all-in-one IP >> >> >> >> >> >> >> >> >> >> >> >> Please crosscheck where I might make mistake and try to correct. >> >> >> >> >> >> >> >> Best regards >> >> >> >> >> >> >> >> Michel >> >> >> >> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >> >> >> etienne.menguy at croit.io> >> >> >> >> wrote: >> >> >> >> >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> There are some information on Ceph documentation >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >> >> >> >>> - Use keystone as auth for RGW >> >> >> >>> - Create service and register your RGW as swift >> >> >> >>> >> >> >> >>> Étienne >> >> >> >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita >> >> wrote: >> >> >> >>>> >> >> >> >>>> Hello , >> >> >> >>>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using ceph >> >> ansible >> >> >> and >> >> >> >>>> create sub user to access the created containers and would like >> to >> >> >> >>> replace >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >> >> configuration >> >> >> to >> >> >> >>> be >> >> >> >>>> done in the OpenStack side in order to integrate those >> services. I >> >> >> have >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu 20.04. >> and >> >> >> ceph >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >> >> >> >>>> >> >> >> >>>> Kindly help for the configuration or documentation. >> >> >> >>>> >> >> >> >>>> Best Regards >> >> >> >>>> >> >> >> >>>> Michel >> >> >> >>>> _______________________________________________ >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >>> >> >> >> >> _______________________________________________ >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From micou12 at gmail.com Thu Sep 2 13:33:57 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Thu, 2 Sep 2021 15:33:57 +0200 Subject: Fwd: Replacing swift with RGW In-Reply-To: References: Message-ID: Hello , I tried to replace Swift RGW but I face some errors 1) the object storage doesnot appear to the dashboard . but it appears in systems information and also it shows the rgw where it points . [image: image.png] the second error I try to run swift command through openstack cli but fails (kolla-open) [stack at kolla-open ~]$ swift -v stat -bash: swift: command not found (kolla-open) [stack at kolla-open ~]$ sudo yum -y install python-swiftclient Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 AM CAT. No match for argument: python-swiftclient Error: Unable to find a match: python-swiftclient (kolla-open) [stack at kolla-open ~]$ . Kindly advise Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 44626 bytes Desc: not available URL: From mark.mielke at gmail.com Thu Sep 2 22:47:42 2021 From: mark.mielke at gmail.com (Mark Mielke) Date: Thu, 2 Sep 2021 18:47:42 -0400 Subject: [nova]is there support for discard/trim in virtio-blk? In-Reply-To: <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> References: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> Message-ID: On Thu, Sep 2, 2021 at 1:47 PM Sean Mooney wrote: > On Thu, 2021-09-02 at 16:48 +0000, Sven Kieske wrote: > > Virtio-blk in upstream Kernel[2] and in qemu[3] does clearly support > > discard/trim, which we discovered thanks to StackExchange[4]. > > > > So my question is, has someone successfully used trim/discard with > > virtio-blk in nova provisioned vms? > and there is an nova config option to enable it. > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_disk_discard > so perhaps you just need to set that o unmap > e.g. > /etc/nova/nova.conf: > [libvirt] > hw_disk_discard=unmap > With a recent enough qemu on hypervisor, and discard support on the block store, it can technically work. However, the guest was the problem for me. For example, I believe the RHEL/CentOS 8.x / 4.18 kernel does NOT provide support for this capability. But, Linux 5.4 works fine. Other than this, it works fine. I have used it for a while now, and it is just bringing the guests up-to-date that prevented it from being more useful. For older guests, I have a simple script that basically fills the guests file system up to 95% full with zero blocks, and the zero block has the same effect on my underlying storage. Finally, I would caveat that discard should not be a storage management solution. The storage should be the right size, and it should get naturally recycled. But, over time - perhaps every few months, or once a year, there is a consequence that guests don't pass through "free" information to the hypervisor on the regular, and it will capture dead blocks in the underlying storage that never get garbage collected, and this is an unfortunate waste. In our case, SolidFire stores the blocks 3X and it adds up. In five years, I've done the clean up with discard or zero only twice. -- Mark Mielke -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Sep 2 23:22:10 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 2 Sep 2021 23:22:10 +0000 Subject: [all][infra] Mailing lists offline 2021-09-12 for server upgrade Message-ID: <20210902232210.jx2hrxpqjmjrn74z@yuggoth.org> n Sunday, September 12, the OpenDev sysadmins will be performing operating system upgrades for the server hosting the lists.airshipit.org, lists.opendev.org, lists.openstack.org, lists.starlingx.io, and lists.zuul-ci.org sites. Expect extended outages for message delivery and access to archives between 15:00 UTC and 21:00 UTC, though messages sent to the mailing lists at these sites should queue normally and be delivered automatically after maintenance activities have concluded. If you have any questions, feel free to reply to this message, or find us in the #opendev channel on the OFTC IRC network. -- 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 Fri Sep 3 06:59:10 2021 From: kkchn.in at gmail.com (KK CHN) Date: Fri, 3 Sep 2021 12:29:10 +0530 Subject: Unable to attach a Volume to Openstack WIndows instance Message-ID: List, I am trying to import a multi disk Windows VM ( 100GB bootable disk and 600 GB data volume disk) exported from HyperV to Openstack(Ussuri, Qemu-KVM, Glance image store, Cinder volume with Ceph backend). I am able to import the First bootable disk(vhdx converted to qcow2 ) with Windows VM in the OpenStack and its up and running able to login. ONE BASIC queston I not perfomed the *"Virt IO Injection steps"* as I am not sure whether for existing Windows VMs exported from HyperV need this Injection or not . Some one can clarify or defend this statement * " That Any Windows VM with Volume disks attached to it running on Other HyperVisor( say HyperV in my case, oVirt) exported to openstack which uses qemu-kvm needed the VirtIO Injection must done before importing to OpenStack with KVM for these Windows VMs for up and running and for attaching volume disks which also exported from other hypervisors . " OR only performance improvement only VirtIO injection do, so that I can avoid VirtIO injection for importing WIndowsVMs with multi disk to OpenStack.* used this step to import the converted bootable disk to my openstack. # openstack image create “Your_Windows_VM_NAME_Blaah” --file Windows_VM_disk1.qcow2 --disk-format qcow2 --container-format bare --public --property hw_firmware_type=uefi --property os_secure_boot=required --property hw_disk_bus=ide I am trying to import the second disk # openstack image create “Your_Windows_VM_NAME_Blah” --file Windows_VM_disk2.qcow2 --disk-format qcow2 --public and tried to create Volume through horizon dashboard with this image and 600 GB space. But volume creation itself showing status creating for more than 1 hour for now . Is this usual behaviour or some this wrong ? Note: so this volume creation from image is taking long time. As trial and error method I tried to create a small plain volume and attach this to the running WIndows VM(Windows2012 RC). But failed. I tried to create a plain 20 GB volume from the Horizon GUI and its created with in 30 seconds.. And tried to attach this volume to the Windows VM disk1 which is running and not got attached. ( I shutdown the Windows VM and tried to attach) same result. not attached. A plain volume also unable to got attached to the Windows VM ? why ? But the large 600GB goes for long hours. ( yesterday also tried and it was in creating state for 5 to 10 hours and I was waiting with no use, then I used the cinder command to change the volume status to "available" and then removed the volume which had not yet changed the state from "creating" to ``available" . Why do these volume creations with large disk space go for hours ? Are there any short steps to make it fast ? Any hints most -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.Kieske at mittwald.de Fri Sep 3 08:15:51 2021 From: S.Kieske at mittwald.de (Sven Kieske) Date: Fri, 3 Sep 2021 08:15:51 +0000 Subject: [nova]is there support for discard/trim in virtio-blk? In-Reply-To: <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> References: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> Message-ID: On Do, 2021-09-02 at 18:44 +0100, Sean Mooney wrote: > although its not clear that libvirt was updated to support the virtio-blk support added in qemu 4.0.0 sicne the libvirt docs were not updated to refernce that. Thanks for all the feedback and pointers! FWIW we were already aware of the discard=unmap option in libvirt, I should have mentioned that. In the meantime I found this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1672682 which seems to indicate that this indeed works in libvirt for virtio-blk. So I will continue to figure out why this doesn't work as intended in our setup. -- 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 kchamart at redhat.com Fri Sep 3 08:32:55 2021 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 3 Sep 2021 10:32:55 +0200 Subject: [nova]is there support for discard/trim in virtio-blk? In-Reply-To: References: <056115b0d76175a5383bab5102c46e67f2375e42.camel@mittwald.de> <81a5394854a9d72ca9f1d4e2254be785da042943.camel@redhat.com> Message-ID: On Fri, Sep 03, 2021 at 08:15:51AM +0000, Sven Kieske wrote: [...] > Thanks for all the feedback and pointers! FWIW we were already aware > of the discard=unmap option in libvirt, I should have mentioned that. > > In the meantime I found this bugreport: > https://bugzilla.redhat.com/show_bug.cgi?id=1672682 > > which seems to indicate that this indeed works in libvirt for > virtio-blk. > > So I will continue to figure out why this doesn't work as intended in > our setup. Yes, 'discard' support for 'virtio-blk' was added to Linux and QEMU in the following versions: - Linux: v5.0 onwards - QEMU: v4.0.0 So make sure you have those versions at a minimum. And as you've discovered in the above Red Hat bugzilla, libvirt already has the config option to enable 'discard'; and Nova has the config option too. * * * Some notes on 'discard' (also called as 'trim') that I learnt from my colleague Dan Berrangé: - To genuinely save storage space, you need to enable 'trim' at every single layer of the I/O stack -- guest, host, and storage server(s). - Even if the host storage doesn't support 'discard', it might still be useful to enable it for the guests -- it'll keep your qcow2 file size down by releasing unused clusters, so if you need to copy the qcow2 file to another host there will be less data needing copying. - If you're "thick-provisoning" your guests so that they will never trigger ENOSPC, then you don't want to enable 'discard'. [...] -- /kashyap From cjeanner at redhat.com Fri Sep 3 10:01:15 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Fri, 3 Sep 2021 12:01:15 +0200 Subject: [TripleO] "cs9" hashtag for changes related to CenOS Stream 9 support Message-ID: <2581ae2f-77ab-bb84-24bd-ac658cbf0129@redhat.com> Hello there, We currently see a nice effort in order to integrate CentOS Stream 9 support in code base and CI. In order to make everything easier to track, it would be really nice if everyone working on that topic could set a simple "cs9" hashtag on their changes. This will allow to follow things with this link: https://review.opendev.org/q/hashtag:%22cs9%22+(status:open%20OR%20status:merged) Thank you in advance! 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 ignaziocassano at gmail.com Fri Sep 3 10:05:36 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 3 Sep 2021 12:05:36 +0200 Subject: [kolla][wallaby][neutron] router ha not working Message-ID: Hello Everyone, I am facing an issue with router-ha in kolla wallaby. In my neutron.conf I inserted l3_ha = True max_l3_agents_per_router = 3 l3_ha_net_cidr = 169.254.192.0/18 but router ha does not work. The router namespace is present only on one of the three contrllers and if the controller goes down routing stop to work. I am using ovs and not ovn. Any help,please ? Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Sep 3 10:09:46 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 3 Sep 2021 12:09:46 +0200 Subject: [kolla][wallaby][neutron] router ha not working In-Reply-To: References: Message-ID: Hello, further information: the l3 agent log on the controllers where router namespace is not present, report: https://paste.openstack.org/show/808573/ Il giorno ven 3 set 2021 alle ore 12:05 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello Everyone, > I am facing an issue with router-ha in kolla wallaby. In my neutron.conf I > inserted l3_ha = True > max_l3_agents_per_router = 3 > l3_ha_net_cidr = 169.254.192.0/18 > but router ha does not work. > The router namespace is present only on one of the three contrllers and if > the controller goes down routing stop to work. > I am using ovs and not ovn. > Any help,please ? > Ignazio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Sep 3 10:28:00 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 3 Sep 2021 12:28:00 +0200 Subject: [kolla][wallaby][neutron] router ha not working In-Reply-To: References: Message-ID: Hello, further information. The controllers where router namespace is absent have issues on openvswitch agent, this is probably the cause of br-int error. The error in openvswitch agent log is reported here: https://paste.openstack.org/show/808576/ Thanks Il giorno ven 3 set 2021 alle ore 12:09 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello, further information: > the l3 agent log on the controllers where router namespace is not present, > report: > https://paste.openstack.org/show/808573/ > > Il giorno ven 3 set 2021 alle ore 12:05 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> Hello Everyone, >> I am facing an issue with router-ha in kolla wallaby. In my neutron.conf >> I inserted l3_ha = True >> max_l3_agents_per_router = 3 >> l3_ha_net_cidr = 169.254.192.0/18 >> but router ha does not work. >> The router namespace is present only on one of the three contrllers and >> if the controller goes down routing stop to work. >> I am using ovs and not ovn. >> Any help,please ? >> Ignazio >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Sep 3 10:37:34 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 3 Sep 2021 12:37:34 +0200 Subject: [kolla][wallaby][neutron] router ha not working In-Reply-To: References: Message-ID: Hello, Sorry for sending informations step by step. Seems kolla does not deploy openvswitch on all controllers :-( Ignazio Il giorno ven 3 set 2021 alle ore 12:28 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello, further information. > The controllers where router namespace is absent have issues on > openvswitch agent, this is probably the cause of br-int error. > The error in openvswitch agent log is reported here: > https://paste.openstack.org/show/808576/ > Thanks > > Il giorno ven 3 set 2021 alle ore 12:09 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> Hello, further information: >> the l3 agent log on the controllers where router namespace is not >> present, report: >> https://paste.openstack.org/show/808573/ >> >> Il giorno ven 3 set 2021 alle ore 12:05 Ignazio Cassano < >> ignaziocassano at gmail.com> ha scritto: >> >>> Hello Everyone, >>> I am facing an issue with router-ha in kolla wallaby. In my neutron.conf >>> I inserted l3_ha = True >>> max_l3_agents_per_router = 3 >>> l3_ha_net_cidr = 169.254.192.0/18 >>> but router ha does not work. >>> The router namespace is present only on one of the three contrllers and >>> if the controller goes down routing stop to work. >>> I am using ovs and not ovn. >>> Any help,please ? >>> Ignazio >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Sep 3 10:49:47 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 3 Sep 2021 12:49:47 +0200 Subject: [kolla][wallaby][neutron] router ha not working In-Reply-To: References: Message-ID: Hello, I solved running again: kolla-ansible -i /etc/kolla/multinode -e ansible_user=ansible -e ansible_become=true deploy -t openvswitch With the above it started openvswitch on all controllers. Stange it does not do it during deployment. Ignazio Il giorno ven 3 set 2021 alle ore 12:37 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello, Sorry for sending informations step by step. > Seems kolla does not deploy openvswitch on all controllers :-( > Ignazio > > Il giorno ven 3 set 2021 alle ore 12:28 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> Hello, further information. >> The controllers where router namespace is absent have issues on >> openvswitch agent, this is probably the cause of br-int error. >> The error in openvswitch agent log is reported here: >> https://paste.openstack.org/show/808576/ >> Thanks >> >> Il giorno ven 3 set 2021 alle ore 12:09 Ignazio Cassano < >> ignaziocassano at gmail.com> ha scritto: >> >>> Hello, further information: >>> the l3 agent log on the controllers where router namespace is not >>> present, report: >>> https://paste.openstack.org/show/808573/ >>> >>> Il giorno ven 3 set 2021 alle ore 12:05 Ignazio Cassano < >>> ignaziocassano at gmail.com> ha scritto: >>> >>>> Hello Everyone, >>>> I am facing an issue with router-ha in kolla wallaby. In my >>>> neutron.conf I inserted l3_ha = True >>>> max_l3_agents_per_router = 3 >>>> l3_ha_net_cidr = 169.254.192.0/18 >>>> but router ha does not work. >>>> The router namespace is present only on one of the three contrllers and >>>> if the controller goes down routing stop to work. >>>> I am using ovs and not ovn. >>>> Any help,please ? >>>> Ignazio >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Fri Sep 3 11:20:52 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Fri, 3 Sep 2021 11:20:52 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1benVuXVtjeWJv?= =?utf-8?B?cmddW2t1cnlyXSBSZTogRWRnZSBmb3Igc2NpZW50aWZpYyByZXNlYXJjaCBz?= =?utf-8?Q?ession_on_September_13_Edge_WG_meeting?= In-Reply-To: References: Message-ID: Hi Ildiko, Currently Cyborg and nova support interaction, we are not very familiar with zun yet, if possible, please provide some relevant information. You can refer to [1] for Cyborg related materials, and [2] for the interactive content of nova and cyborg (not yet merged). [1]https://docs.openstack.org/cyborg/latest/user/architecture.html [2]https://review.opendev.org/c/openstack/cyborg/+/794549 https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/nova-cyborg-interaction.html Bailin Zhang (brinzhang) -----邮件原件----- 发件人: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] 发送时间: 2021年8月31日 22:39 收件人: openstack-discuss 主题: [lists.openstack.org代发][zun][cyborg][kuryr] Re: Edge for scientific research session on September 13 Edge WG meeting 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 hberaud at redhat.com Fri Sep 3 14:37:36 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 3 Sep 2021 16:37:36 +0200 Subject: [release] Release countdown for week R-4, Sep 06 - Sep 10 Message-ID: Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the Xena deliverables can be proposed, well ahead of the final Xena release date (06 October, 2021). General Information ------------------- We are still finishing up processing a few release requests, but the Xena release requirements are now frozen. If new library releases are needed to fix release-critical bugs in Xena, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in Xena that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By 30 September this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/xena branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Xena changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed Xena cycle-highlights yet, you are already late to the party. Please see http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024105.html for details. Upcoming Deadlines & Dates -------------------------- RC1 deadline: 16 September (R-3 week) Final RC deadline: 30 September (R-1 week) Final Xena release: 6 October 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 gmann at ghanshyammann.com Fri Sep 3 16:48:16 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 03 Sep 2021 11:48:16 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 3rd Sept, 21: Reading: 5 min Message-ID: <17bac8f950b.d351de0649259.4664258300272619635@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 (Video call) on Sept 2nd 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 video recording@ (we will find a better place to put the recording next time.) - https://drive.google.com/drive/folders/16NiC60Gm8BXjZw6XCJrto6lMi6OigTiQ?usp=sharing * We will have next week's meeting on Sept 9th, Thursday 15:00 UTC on IRC, feel free the topic in agenda [1] by Sept 8th. 2. What we completed this week: ========================= * Closeout Yoga TC Election[2] * Added two more release liaisons for Keystone[3] * Retired puppet-monasca[4] 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[5] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Five open reviews for ongoing activities[6]. Combined PTL/TC Election Season for Yoga ---------------------------------------------------- * TC election are closeout[2]. * TC chair and vice-chair nomination are also up for review/vote. * PTL election (Cyborg project having election) is going on. Leaderless projects ----------------------- * From the current nomination, we have six leaderless projects[7]. Out of them, we have five projects leaders volunteer (a few are late candidacy). One project 'Adjutant' still needs someone to step up to lead this project. Please add your name to etherpad if you are interested. Rico will also be reaching out to the previous PTL and team about it. New project application: 'Venus' -------------------------------------- * We discussed this application and all the queries are answered either on patch or ML. TC decided to start the voting in Gerrit patch[8]. Collecting Pain points from projects/SIGs/pop-up ----------------------------------------------------------- * We spend most of the meeting time on this topic. We have not gone through all the pain points mentioned in etherpad[9] but collecting two common pain points 1. rabbitMQ 2. OSC which we should continue or start discussing at the TC level. Other pain points are more project-specific. * We will continue discussing it in PTG, join us if you are interested to help/discuss this topic. Project updates ------------------- * Retiring js-openstack-lib [10] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [11]. * Current status: "Secure RBAC" is selected for Yoga cycle[12]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[13], feel free to add any topic you would like to discuss. * We discussed the live stream of one of the TC PTG sessions like we did last time. Once we will have more topics in etherpad then we can select the appropriate one. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[14], 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[15]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [16] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [17] 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/+/806270 [3] https://review.opendev.org/c/openstack/governance/+/806615 [4] https://review.opendev.org/c/openstack/governance/+/805105 [5] https://etherpad.opendev.org/p/tc-xena-tracker [6] https://review.opendev.org/q/project:openstack/governance+status:open [7] https://etherpad.opendev.org/p/yoga-leaderless [8] https://review.opendev.org/c/openstack/governance/+/804824 [9] https://etherpad.opendev.org/p/pain-point-elimination [10] https://review.opendev.org/c/openstack/governance/+/798540 [11] https://etherpad.opendev.org/p/y-series-goals [12] https://review.opendev.org/c/openstack/governance/+/803783 [13] https://etherpad.opendev.org/p/tc-yoga-ptg [14] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [15] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [16] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [17] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann From ces.eduardo98 at gmail.com Fri Sep 3 19:21:21 2021 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Fri, 3 Sep 2021 16:21:21 -0300 Subject: [manila][FFE] Feature freeze exception request Message-ID: Hello, everyone! I'd like to request feature freeze exceptions to some changes: [1] https://review.opendev.org/c/openstack/manila/+/803623 - Enhancements to Manila's share server migration mechanism. It will allow administrators to perform non-disruptive migrations of share servers in the cloud. [2] https://review.opendev.org/c/openstack/manila/+/803624 - New share server migration mechanism added to the NetApp ONTAP driver. With this, administrators will be able to migrate share servers nondisruptively. [3] https://review.opendev.org/c/openstack/manila/+/803622 Add support for FlexGroups in the NetApp ONTAP driver for Manila. With this feature, petabyte scale filesystems will be feasible. All changes I have mentioned were submitted in time in the feature proposal freeze for Manila, and there has been significant progress in the reviews until this point. We're working through the last of the minor enhancements reviewers have called for. These changes are isolated to the NetApp driver module, and have no impact to the manila database, REST/RPC API. Regards, carloss -------------- next part -------------- An HTML attachment was scrubbed... URL: From 22rahulmiragi at gmail.com Fri Sep 3 19:41:57 2021 From: 22rahulmiragi at gmail.com (Rahul Miragi) Date: Sat, 4 Sep 2021 01:11:57 +0530 Subject: [Neutron] [Kolla ansible ] external network setting for vlan Message-ID: Hi team, I am using kolla ansible to deploy wallaby release on single node. I have successfully deployed it and now I want to create external network and attach external IPs to openstack VMs. But somehow I’m unable to configure it. Could you please share some articles or config examples. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Fri Sep 3 20:55:04 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Fri, 3 Sep 2021 16:55:04 -0400 Subject: [cinder] xena feature freeze Message-ID: The Xena feature freeze for cinder is now in effect. Please do not approve patches proposing features for master until after the stable/xena branch has been cut the week of 13 September. The following blueprints are granted feature freeze exceptions: - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x - https://blueprints.launchpad.net/cinder/+spec/remove-sqlalchemy-migrate Any other feature patches (including driver features) that have not yet merged and are associated with an approved xena blueprint may apply for a Feature Freeze Exception by replying to this email before Tuesday, 7 September at 20:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Xena. It is expected that patches granted an FFE will be merged by 21:00 UTC on Monday 13 September. Bugfixes do not require an FFE. To be included in Xena, they must be merged before the first Release Candidate is cut on Thursday 16 September. After that point, only release-critical bugfixes will be allowed into the Xena release. Ping me in IRC if you have any questions. cheers, brian From fernandoperches at gmail.com Fri Sep 3 21:09:04 2021 From: fernandoperches at gmail.com (Fernando Ferraz) Date: Fri, 3 Sep 2021 18:09:04 -0300 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: Hi Team, I'd like to request FFE to the following changes: [1] Netapp ONTAP: Add support to revert to snapshot https://review.opendev.org/c/openstack/cinder/+/804093 - Patch adds support for the revert to snapshot feature to the NetApp Cinder drivers. [2] NetApp ONTAP: Add option to report storage provisioned capacity https://review.opendev.org/c/openstack/cinder/+/798198 - Patch adds an option to enable a new pool capability provisioned_capacity_gb that reports storage provisioned volume sizes directly from the storage system, instead of relying on the default scheduler's behavior based on internal states. Both changes and their blueprints were submitted in time and there has been significant progress in the reviews until this point. They are isolated to the NetApp driver module, and have no impact on the Cinder database, REST/RPC and APIs. Regards, Fernando Em sex., 3 de set. de 2021 às 18:01, Brian Rosmaita < rosmaita.fossdev at gmail.com> escreveu: > The Xena feature freeze for cinder is now in effect. Please do not > approve patches proposing features for master until after the > stable/xena branch has been cut the week of 13 September. > > The following blueprints are granted feature freeze exceptions: > - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x > - https://blueprints.launchpad.net/cinder/+spec/remove-sqlalchemy-migrate > > Any other feature patches (including driver features) that have not yet > merged and are associated with an approved xena blueprint may apply for > a Feature Freeze Exception by replying to this email before Tuesday, 7 > September at 20:00 UTC. Note that application for an FFE is not a > guarantee that an FFE will be granted. Grant of an FFE is not a > guarantee that the code will be merged for Xena. > > It is expected that patches granted an FFE will be merged by 21:00 UTC > on Monday 13 September. > > Bugfixes do not require an FFE. To be included in Xena, they must be > merged before the first Release Candidate is cut on Thursday 16 > September. After that point, only release-critical bugfixes will be > allowed into the Xena release. > > Ping me in IRC if you have any questions. > > cheers, > brian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Fri Sep 3 23:04:11 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Fri, 3 Sep 2021 16:04:11 -0700 Subject: [manila][FFE] Feature freeze exception request In-Reply-To: References: Message-ID: On Fri, Sep 3, 2021 at 12:27 PM Carlos Silva wrote: > Hello, everyone! > > I'd like to request feature freeze exceptions to some changes: > [1] https://review.opendev.org/c/openstack/manila/+/803623 > - Enhancements to Manila's share server migration mechanism. It will allow > administrators to perform non-disruptive migrations of share servers in the > cloud. > > [2] https://review.opendev.org/c/openstack/manila/+/803624 > - New share server migration mechanism added to the NetApp ONTAP driver. > With this, administrators will be able to migrate share servers > nondisruptively. > > [3] https://review.opendev.org/c/openstack/manila/+/803622 > Add support for FlexGroups in the NetApp ONTAP driver for Manila. With > this feature, petabyte scale filesystems will be feasible. > > All changes I have mentioned were submitted in time in the feature > proposal freeze for Manila, and there has been significant progress in the > reviews until this point. We're working through the last of the minor > enhancements reviewers have called for. These changes are isolated to the > NetApp driver module, and have no impact to the manila database, REST/RPC > API. > Thanks Carlos. Agreed; thanks for your hard work iterating through reviews. Just a friendly reminder - we’re at a long weekend holiday in many parts of the world, including where you are. I hope you enjoy the time off - we can take a little bit longer to get these in. Thanks, Goutham > Regards, > carloss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joykechen at 163.com Sat Sep 4 14:59:41 2021 From: joykechen at 163.com (=?GBK?B?s8K/yw==?=) Date: Sat, 4 Sep 2021 22:59:41 +0800 (CST) Subject: [zun][cyborg][kuryr] Re: Edge for scientific research session on September 13 Edge WG meeting In-Reply-To: References: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> Message-ID: <2ff99838.2b86.17bb1528b2a.Coremail.joykechen@163.com> Hi Ildiko, I'm a Cyborg core. I think it's cool to promote the integration of Cyborg and Zun. I'm happy to push the whole thing if I could. Zun's PTL Shengqin Feng is my colleague. I suggest you send her and me a reminder email before the meeting. Her Email: feng.shengqin at zte.com.cn Thanks, Ke Chen At 2021-08-31 22:39:01, "Ildiko Vancsa" wrote: >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. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasufum.o at gmail.com Mon Sep 6 05:03:33 2021 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Mon, 6 Sep 2021 14:03:33 +0900 Subject: [tacker] Ayumu Ueha for Tacker Core Message-ID: Hi everyone, I'd like to propose Ayumu Ueha as a core reviewer. He has made huge contributions not only for reviewing actively but also developing key features of NFV Container support and helping us for fixing critical problems [1][2]. Assuming that there are no objections, we will add Ayumu to tacker core team next week. [1] https://review.opendev.org/q/owner:ayumu [2] https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_id=ueha From yamakawa.keiich at fujitsu.com Mon Sep 6 06:01:55 2021 From: yamakawa.keiich at fujitsu.com (yamakawa.keiich at fujitsu.com) Date: Mon, 6 Sep 2021 06:01:55 +0000 Subject: [tacker] Ayumu Ueha for Tacker Core In-Reply-To: References: Message-ID: +1 Best regards. -----Original Message----- From: Yasufumi Ogawa Sent: Monday, September 6, 2021 2:04 PM To: openstack-discuss Subject: [tacker] Ayumu Ueha for Tacker Core Hi everyone, I'd like to propose Ayumu Ueha as a core reviewer. He has made huge contributions not only for reviewing actively but also developing key features of NFV Container support and helping us for fixing critical problems [1][2]. Assuming that there are no objections, we will add Ayumu to tacker core team next week. [1] https://review.opendev.org/q/owner:ayumu [2] https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_id=ueha From katada.yoshiyuk at fujitsu.com Mon Sep 6 06:08:13 2021 From: katada.yoshiyuk at fujitsu.com (katada.yoshiyuk at fujitsu.com) Date: Mon, 6 Sep 2021 06:08:13 +0000 Subject: [tacker] Ayumu Ueha for Tacker Core In-Reply-To: References: Message-ID: +1 Best Regards -----Original Message----- From: Yasufumi Ogawa [mailto:yasufum.o at gmail.com] Sent: Monday, September 6, 2021 2:04 PM To: openstack-discuss Subject: [tacker] Ayumu Ueha for Tacker Core Hi everyone, I'd like to propose Ayumu Ueha as a core reviewer. He has made huge contributions not only for reviewing actively but also developing key features of NFV Container support and helping us for fixing critical problems [1][2]. Assuming that there are no objections, we will add Ayumu to tacker core team next week. [1] https://review.opendev.org/q/owner:ayumu [2] https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_id=ueha From kaurmanpreet2620 at gmail.com Mon Sep 6 06:13:50 2021 From: kaurmanpreet2620 at gmail.com (manpreet kaur) Date: Mon, 6 Sep 2021 11:43:50 +0530 Subject: [tacker] Ayumu Ueha for Tacker Core In-Reply-To: References: Message-ID: +1 Thanks & Regards, Manpreet Kaur On Mon, Sep 6, 2021 at 11:41 AM katada.yoshiyuk at fujitsu.com < katada.yoshiyuk at fujitsu.com> wrote: > +1 > Best Regards > -----Original Message----- > From: Yasufumi Ogawa [mailto:yasufum.o at gmail.com] > Sent: Monday, September 6, 2021 2:04 PM > To: openstack-discuss > Subject: [tacker] Ayumu Ueha for Tacker Core > > Hi everyone, > > I'd like to propose Ayumu Ueha as a core reviewer. He has made huge > contributions not only for reviewing actively but also developing key > features of NFV Container support and helping us for fixing critical > problems [1][2]. > > Assuming that there are no objections, we will add Ayumu to tacker core > team next week. > > [1] https://review.opendev.org/q/owner:ayumu > [2] > > https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_id=ueha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts-takahashi at nec.com Mon Sep 6 06:37:01 2021 From: ts-takahashi at nec.com (=?utf-8?B?VEFLQUhBU0hJIFRPU0hJQUtJKOmrmOapi+OAgOaVj+aYjik=?=) Date: Mon, 6 Sep 2021 06:37:01 +0000 Subject: [tacker] Ayumu Ueha for Tacker Core In-Reply-To: References: Message-ID: +1. That's nice! Regards, Toshiaki > -----Original Message----- > From: Yasufumi Ogawa > Sent: Monday, September 6, 2021 2:04 PM > To: openstack-discuss > Subject: [tacker] Ayumu Ueha for Tacker Core > > Hi everyone, > > I'd like to propose Ayumu Ueha as a core reviewer. He has made huge > contributions not only for reviewing actively but also developing key features of > NFV Container support and helping us for fixing critical problems [1][2]. > > Assuming that there are no objections, we will add Ayumu to tacker core team > next week. > > [1] https://review.opendev.org/q/owner:ayumu > [2] > https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&us > er_id=ueha From katonalala at gmail.com Mon Sep 6 07:06:17 2021 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 6 Sep 2021 09:06:17 +0200 Subject: [Neutron] [Kolla ansible ] external network setting for vlan In-Reply-To: References: Message-ID: Hi Rahul, Not sure where You started your research so I add some basic documentation (but it has links to further docs): - Openstack Networking concepts: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html - Deployment with OVS (not sure which mechanism driver You use): https://docs.openstack.org/neutron/latest/admin/deploy-ovs.html - here You can find config and CLI examples if You open the links. Lajos (lajoskatona) Rahul Miragi <22rahulmiragi at gmail.com> ezt írta (időpont: 2021. szept. 3., P, 21:46): > Hi team, > > I am using kolla ansible to deploy wallaby release on single node. I have > successfully deployed it and now I want to create external network and > attach external IPs to openstack VMs. But somehow I’m unable to configure > it. Could you please share some articles or config examples. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Mon Sep 6 07:22:58 2021 From: kkchn.in at gmail.com (KK CHN) Date: Mon, 6 Sep 2021 12:52:58 +0530 Subject: Error adding a Plain Volume created through GUI to Instance Message-ID: ExecutionError: Unexpected error while running command. Command: rbd map volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 --pool volumes --id volumes --mon_host 10.236.223.131:6789 --mon_host 10.236.223.132:6789 Exit code: 6 Stdout: 'RBD image feature set mismatch. You can disable features unsupported by the kernel with "rbd feature disable volumes/volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 journaling".\nIn some cases useful info is found in syslog - try "dmesg | tail".\n' Stderr: 'rbd: sysfs write failed\nrbd: map failed: (6) No such device or address\n' I am trying to add a 20 GB plain volume created through Horizon GUI to an existing Windows 2012 R VM running with VirtIO drivers installed. But this volume adding results in the error as shown above, trace tells to fix it by rbd feature disable .. what is the permanent fix for this issue ? and why it happens ? ( OpenStack Ussuri, Glance, Ceph , qemu-kvm) root at ctrl1:/home/cloud# ceph --version ceph version 14.2.19 (bb796b9b5bab9463106022eef406373182465d11) nautilus (stable) root at ctrl1:/home/cloud# -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Sep 6 07:35:54 2021 From: zigo at debian.org (Thomas Goirand) Date: Mon, 6 Sep 2021 09:35:54 +0200 Subject: [horizon] Support for Django 3.x Message-ID: Hi, It's been a long time that Django 3.x is around, and therefore, it'd be nice if Horizon had some kind of support for it. Indeed, sooner or later, Django 3.x will be uploaded to Debian unstable. That day, I hope Horizon doesn't just break. So, what's the status? Is anyone is at least working on it? Cheers, Thomas Goirand (zigo) From stefan.hoffmann at cloudandheat.com Mon Sep 6 08:11:37 2021 From: stefan.hoffmann at cloudandheat.com (Stefan Hoffmann) Date: Mon, 06 Sep 2021 10:11:37 +0200 Subject: [cinder] discuss nas_secure options and root_squash (prohibiting root access to share) In-Reply-To: <9884c0fb2ffac6ef7ab9aeae2d1c692149a5a799.camel@cloudandheat.com> References: <9884c0fb2ffac6ef7ab9aeae2d1c692149a5a799.camel@cloudandheat.com> Message-ID: <83f3a77171aa27a92df4958f9c5d5514a2048e96.camel@cloudandheat.com> Hi cinder team, do you have any feedback, if this approach [1] follows the "right" way now? Will add this point to the meeting this week, would be nice, if you can have a look before, so we can discuss about it. Regards Stefan [1] https://review.opendev.org/c/openstack/cinder/+/802882 On Mon, 2021-08-16 at 18:05 +0200, Stefan Hoffmann wrote: > 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: This is a digitally signed message part URL: From mdemaced at redhat.com Mon Sep 6 08:17:17 2021 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Mon, 6 Sep 2021 10:17:17 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello, Just some extra thought, did you check if there is some process running on port 8080? It's possible that the API failed to start, is Kuryr being used? Thanks, Maysa Macedo. On Tue, Aug 31, 2021 at 1:57 PM Karera Tony wrote: > 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 openinfradn at gmail.com Mon Sep 6 08:32:36 2021 From: openinfradn at gmail.com (open infra) Date: Mon, 6 Sep 2021 14:02:36 +0530 Subject: flavor with GPU Message-ID: Hi, How to create a flavor with GPU? The way we set vcpu and memory. Regards, Danishka -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Sep 6 08:51:37 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 06 Sep 2021 10:51:37 +0200 Subject: [nova][placement] nova-next job is broken Message-ID: <1M80ZQ.S70WTG0D8TSL1@est.tech> Hi, Since Friday the nova-next job fails with POST_FAILURE[1] due to the new osc-placement release. Please hold you rechecks. [1] https://bugs.launchpad.net/nova/+bug/1942740 Cheers, gibi From masazumi.oota.ds at hco.ntt.co.jp Mon Sep 6 09:27:09 2021 From: masazumi.oota.ds at hco.ntt.co.jp (=?UTF-8?B?5aSq55Sw5q2j57SU?=) Date: Mon, 06 Sep 2021 18:27:09 +0900 Subject: [tacker] Ayumu Ueha for Tacker Core In-Reply-To: References: Message-ID: <2764fd17-2dd5-59a4-dc9b-a28a44024847@hco.ntt.co.jp> +1 Best regards. On 2021/09/06 14:03, Yasufumi Ogawa wrote: > Hi everyone, > > I'd like to propose Ayumu Ueha as a core reviewer. He has made huge > contributions not only for reviewing actively but also developing key > features of NFV Container support and helping us for fixing critical > problems [1][2]. > > Assuming that there are no objections, we will add Ayumu to tacker core > team next week. > > [1] https://review.opendev.org/q/owner:ayumu > [2] > https://www.stackalytics.io/?module=opendev.org%2fopenstack%2ftacker&user_id=ueha > > -- --------------------------------- Masazumi OTA(太田 正純) NTT Network Innovation Center（NTT NIC) masazumi.oota.ds at hco.ntt.co.jp 0422-59-3396 From micou12 at gmail.com Mon Sep 6 09:34:08 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Mon, 6 Sep 2021 11:34:08 +0200 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: Hello, I am trying to replace swift by RGW as backend storage but I failed once I try to post a container in the OpenStack side however, all interfaces are configured (admin, public and internal). but Once I post from RGW host it is created . Another issue is that object storage does not appear on the horizon dashboard . I have deployed openstack all-in-one using kolla-ansible and Os is ubuntu (kolla-open1) stack at kolla-open1:~$ swift -v post myswift Container POST failed: http://ceph-osd3:8080/swift/v1/myswift 401 Unauthorized b'AccessDenied' Failed Transaction ID: tx000000000000000000008-006135dcbd-87d63-default (kolla-open1) stack at kolla-open1:~$ swift list Account GET failed: http://ceph-osd3:8080/swift/v1?format=json 401 Unauthorized [first 60 chars of response] b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000c-' Failed Transaction ID: tx00000000000000000000c-006135de42-87d63-default Kindly help to solve the issue Michel On Thu, Sep 2, 2021 at 4:28 PM Alex Schultz wrote: > The swift docs are a bit out of date as they still reference python2 > despite python3 being supported for some time now. Replace python- with > python3- and try again. > > > On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita wrote: > >> >> >> ---------- Forwarded message --------- >> From: Michel Niyoyita >> Date: Thu, Sep 2, 2021 at 12:17 PM >> Subject: Fwd: [ceph-users] Re: Replacing swift with RGW >> To: >> >> >> >> >> ---------- Forwarded message --------- >> From: Eugen Block >> Date: Thu, Sep 2, 2021 at 10:39 AM >> Subject: Re: [ceph-users] Re: Replacing swift with RGW >> To: Michel Niyoyita >> >> >> You should continue this thread on the openstack-discuss mailing list >> (openstack-discuss at lists.openstack.org) since this is not a ceph issue. >> I'm not familiar with kolla and I don't know the requirements to >> install openstack-swift, you'll need to ask the openstack community. >> >> >> Zitat von Michel Niyoyita : >> >> > Below are errors I am getting once I try to run swift commands . the >> second >> > one is the error I get once try to install python-swiftclient >> > >> > (kolla-open) [stack at kolla-open ~]$ swift -v stat >> > -bash: swift: command not found >> > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install >> python-swiftclient >> > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 >> AM >> > CAT. >> > No match for argument: python-swiftclient >> > Error: Unable to find a match: python-swiftclient >> > (kolla-open) [stack at kolla-open ~]$ >> > >> > Waiting for your help >> > >> > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: >> > >> >> I can't tell for sure, but yes, I believe you need the openstack-swift >> >> package (with dependencies). What errors do you get? The more >> >> information you share the better people can help. >> >> >> >> >> >> Zitat von Michel Niyoyita : >> >> >> >> > I tried to install "sudo yum -y install python-swiftclient" on >> openstack >> >> > side but fails . are there openastack-shwift packages which are >> needed? >> >> > if are there please help me to get . may be also it is the cause I >> am >> >> > failing to run swift command on openstack cli side. >> >> > >> >> > thank you for your continued support. >> >> > >> >> > Micheal >> >> > >> >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >> >> > >> >> >> I only configured the endpoints for the clients to directly access >> the >> >> >> RGWs, but you'll probably need to install the openstack-swift >> package. >> >> >> Or have you done that already? >> >> >> >> >> >> >> >> >> Zitat von Michel Niyoyita : >> >> >> >> >> >> > Thank you Eugen for your prompt response. >> >> >> > >> >> >> > Now the commands provided work. but I am not finding the object >> >> storage >> >> >> on >> >> >> > the horizon dashboard , but it appears in the system information >> >> >> services. >> >> >> > [image: image.png] >> >> >> > so my question is how to configure it in order that it can appear >> in >> >> the >> >> >> > dashboard . >> >> >> > >> >> >> > Michel >> >> >> > >> >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block wrote: >> >> >> > >> >> >> >> Sorry, one little detail slipped through, the '--region' flag >> has to >> >> >> >> be put before the 'service' name. The correct command would be: >> >> >> >> >> >> >> >> openstack endpoint create --region RegionOne swift admin >> >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> >> >> >> >> and respectively for the other interfaces. >> >> >> >> >> >> >> >> >> >> >> >> Zitat von Eugen Block : >> >> >> >> >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > this is not a ceph issue but your openstack cli command as the >> >> error >> >> >> >> > message states. >> >> >> >> > >> >> >> >> > Try one interface at a time: >> >> >> >> > >> >> >> >> > openstack endpoint create swift public >> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> >> > openstack endpoint create swift admin >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> > --region RegionOne swift >> >> >> >> > openstack endpoint create swift internal >> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >> >> >> > >> >> >> >> > >> >> >> >> > Zitat von Michel Niyoyita : >> >> >> >> > >> >> >> >> >> Hello , >> >> >> >> >> >> >> >> >> >> Below are errors I am getting once I am trying to integrate >> swift >> >> >> with >> >> >> >> >> Radosgateway. >> >> >> >> >> >> >> >> >> >> From openstack side once i try to endpoint which will point >> to the >> >> >> >> >> radosgateway : >> >> >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint >> create >> >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >> >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >> >> >> >> http://ceph-osd3:8080/swift/v1 >> >> >> >> >> --region RegionOne swift >> >> >> >> >> usage: openstack endpoint create [-h] [-f >> >> >> {json,shell,table,value,yaml}] >> >> >> >> >> [-c COLUMN] [--noindent] >> [--prefix >> >> >> >> PREFIX] >> >> >> >> >> [--max-width ] >> >> [--fit-width] >> >> >> >> >> [--print-empty] [--region >> >> >> ] >> >> >> >> >> [--enable | --disable] >> >> >> >> >> >> >> >> >> >> openstack endpoint create: error: argument : >> invalid >> >> >> choice: >> >> >> >> ' >> >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', >> 'public', >> >> >> >> 'internal') >> >> >> >> >> >> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >> >> >> >> >> >> >> >> >> >> below are my /etc/ceph/ceph.conf file : >> >> >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3] >> >> >> >> >> rgw_dns_name = ceph-osd3 >> >> >> >> >> host = ceph-osd3 >> >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >> >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 >> num_threads=100 >> >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >> >> >> >> >> rgw_keystone_admin_user=admin >> >> >> >> >> rgw_keystone_admin_password=admin >> >> >> >> >> rgw_keystone_admin_tenant=admin >> >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >> >> >> >> >> rgw_keystone_token_cache_size=200 >> >> >> >> >> rgw_keystone_revocation_interval=300 >> >> >> >> >> >> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >> >> >> >> >> host = ceph-osd3 >> >> >> >> >> keyring = >> /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >> >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >> >> >> >> >> rgw thread pool size = 512 >> >> >> >> >> >> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with >> 10.10.29.110 as >> >> IP >> >> >> >> >> >> >> >> >> >> and 10.10.29.150 all-in-one IP >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Please crosscheck where I might make mistake and try to >> correct. >> >> >> >> >> >> >> >> >> >> Best regards >> >> >> >> >> >> >> >> >> >> Michel >> >> >> >> >> >> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >> >> >> >> etienne.menguy at croit.io> >> >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >>> Hi, >> >> >> >> >>> >> >> >> >> >>> There are some information on Ceph documentation >> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >> >> >> >> >>> - Use keystone as auth for RGW >> >> >> >> >>> - Create service and register your RGW as swift >> >> >> >> >>> >> >> >> >> >>> Étienne >> >> >> >> >>> >> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita < >> micou12 at gmail.com> >> >> >> wrote: >> >> >> >> >>>> >> >> >> >> >>>> Hello , >> >> >> >> >>>> >> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using ceph >> >> >> ansible >> >> >> >> and >> >> >> >> >>>> create sub user to access the created containers and would >> like >> >> to >> >> >> >> >>> replace >> >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >> >> >> configuration >> >> >> >> to >> >> >> >> >>> be >> >> >> >> >>>> done in the OpenStack side in order to integrate those >> >> services. I >> >> >> >> have >> >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu >> 20.04. >> >> and >> >> >> >> ceph >> >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >> >> >> >> >>>> >> >> >> >> >>>> Kindly help for the configuration or documentation. >> >> >> >> >>>> >> >> >> >> >>>> Best Regards >> >> >> >> >>>> >> >> >> >> >>>> Michel >> >> >> >> >>>> _______________________________________________ >> >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >>> >> >> >> >> >>> _______________________________________________ >> >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >>> >> >> >> >> >> _______________________________________________ >> >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From geguileo at redhat.com Mon Sep 6 09:41:03 2021 From: geguileo at redhat.com (Gorka Eguileor) Date: Mon, 6 Sep 2021 11:41:03 +0200 Subject: Error adding a Plain Volume created through GUI to Instance In-Reply-To: References: Message-ID: <20210906094103.sn4bn6qb4sab3p2m@localhost> On 06/09, KK CHN wrote: > ExecutionError: Unexpected error while running command. > Command: rbd map volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 --pool volumes > --id volumes --mon_host 10.236.223.131:6789 --mon_host 10.236.223.132:6789 > Exit code: 6 > Stdout: 'RBD image feature set mismatch. You can disable features > unsupported by the kernel with "rbd feature disable > volumes/volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 journaling".\nIn some > cases useful info is found in syslog - try "dmesg | tail".\n' > Stderr: 'rbd: sysfs write failed\nrbd: map failed: (6) No such device or > address\n' > > I am trying to add a 20 GB plain volume created through Horizon GUI to an > existing Windows 2012 R VM running with VirtIO drivers installed. But this > volume adding results in the error as shown above, > > trace tells to fix it by rbd feature disable .. what is the > permanent fix for this issue ? and why it happens ? > > ( OpenStack Ussuri, Glance, Ceph , qemu-kvm) > > root at ctrl1:/home/cloud# ceph --version > ceph version 14.2.19 (bb796b9b5bab9463106022eef406373182465d11) nautilus > (stable) > root at ctrl1:/home/cloud# Hi, Usually RBD volumes are directly attached on the hypervisor, but there was an encryption performance issue [1] so nova and os-brick added support to attaching these volumes to the host and then use them on the VM. Attaching volumes on the host uses the krbd module, whereas attaching them to the hypervisor directly uses librbd, with the first one lagging in terms of Ceph features. The issue you are facing is that the images in RBD are being created with features that are not supported by krbd. Fixes are: - Disable those features in your ceph configuration file (usually /etc/ceph/ceph.conf) Under [global] section add: rbd default features = 3 - Change "[workarounds]rbd_volume_local_attach" to False in Nova's config. Cheers, Gorka. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1762765 From wodel.youchi at gmail.com Mon Sep 6 09:48:05 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 6 Sep 2021 10:48:05 +0100 Subject: Does ceph and openstack communicate over the openstack-API network? Message-ID: Hi, Does ceph and openstack communicate over the openstack-API network, for nova, cinder, ...etc to be able to use ceph pools? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Sep 6 10:42:24 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 06 Sep 2021 12:42:24 +0200 Subject: flavor with GPU In-Reply-To: References: Message-ID: On Mon, Sep 6, 2021 at 14:02, open infra wrote: > Hi, > > How to create a flavor with GPU? This document helps with the vGPU support in nova: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html If you need a whole physical GPU to be passed to the guest instead then you can pass that through as a PCI device. Documented here: https://docs.openstack.org/nova/latest/admin/pci-passthrough.html Cheers, gibi > The way we set vcpu and memory. > > Regards, > Danishka From balazs.gibizer at est.tech Mon Sep 6 10:51:33 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 06 Sep 2021 12:51:33 +0200 Subject: [nova][placement] Xena release In-Reply-To: References: Message-ID: Hi, On Thu, Aug 19, 2021 at 11:27, Balazs Gibizer wrote: > 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. As of last Friday we hit Feature Freeze. So still open features needs to be re-proposed to Yoga. The nova-spec repo and launchpad can be used to propose thing to yoga already. If you have a feature that is really close to land the please follow the above FFE process. If you have a feature patch that was approved before the freeze but not landed yet then those patches can be rechecked or rebased and re-approved if needed. Please let the core team know. Cheers, gibi > > Cheers, > gibi > > [1] https://etherpad.opendev.org/p/nova-xena-rc-potential > > > > From tpb at dyncloud.net Mon Sep 6 10:53:17 2021 From: tpb at dyncloud.net (Tom Barron) Date: Mon, 6 Sep 2021 06:53:17 -0400 Subject: Does ceph and openstack communicate over the openstack-API network? In-Reply-To: References: Message-ID: <20210906105317.xuldv354zq663hw4@barron.net> On 06/09/21 10:48 +0100, wodel youchi wrote: >Hi, > >Does ceph and openstack communicate over the openstack-API network, for >nova, cinder, ...etc to be able to use ceph pools? > >Regards. Generally it's not a good idea to combine the openstack API network and the Ceph "public" network since you want to reserve access to the latter to the cloud infrastructure itself (compute nodes, controllers) -- which is under control of the cloud administrators -- and prevent regular users (tenants) from accessing the storage infrastructure. From openinfradn at gmail.com Mon Sep 6 10:56:57 2021 From: openinfradn at gmail.com (open infra) Date: Mon, 6 Sep 2021 16:26:57 +0530 Subject: flavor with GPU In-Reply-To: References: Message-ID: Thanks Balazs. If I already create vgpu I just need to update the flavor using the following command? openstack flavor set vgpu_1 --property "resources:VGPU=1" On Mon, Sep 6, 2021 at 4:12 PM Balazs Gibizer wrote: > > > On Mon, Sep 6, 2021 at 14:02, open infra wrote: > > Hi, > > > > How to create a flavor with GPU? > This document helps with the vGPU support in nova: > https://docs.openstack.org/nova/latest/admin/virtual-gpu.html > > If you need a whole physical GPU to be passed to the guest instead then > you can pass that through as a PCI device. Documented here: > https://docs.openstack.org/nova/latest/admin/pci-passthrough.html > > Cheers, > gibi > > > The way we set vcpu and memory. > > > > Regards, > > Danishka > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.dibbo at stfc.ac.uk Mon Sep 6 10:57:43 2021 From: alexander.dibbo at stfc.ac.uk (Alexander Dibbo - STFC UKRI) Date: Mon, 6 Sep 2021 10:57:43 +0000 Subject: Adding another cell(v2) Message-ID: Hi, Could someone point me to the documentation on how to add a new cell to cellsv2? I have found various documentation that says to follow the procedure for Cells V1 but I cant find documentation for that. Below is the link to the doc I have found https://docs.openstack.org/nova/train/user/cells.html I am running train and have found myself needing to use more cells to deal with our latest hardware deployment. We use a home rolled deployment system. Thanks In Advance Regards Alexander Dibbo - Cloud Architect / Cloud Operations Group Leader For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/ This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Sep 6 10:59:28 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 06 Sep 2021 12:59:28 +0200 Subject: flavor with GPU In-Reply-To: References: Message-ID: <4JE0ZQ.8R16JSDM1MXZ@est.tech> On Mon, Sep 6, 2021 at 16:26, open infra wrote: > Thanks Balazs. > > If I already create vgpu I just need to update the flavor using the > following command? > > openstack flavor set vgpu_1 --property "resources:VGPU=1" Yes, that is the way to request a VGPU via a flavor [1] [1] https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#configure-a-flavor-controller gibi > > On Mon, Sep 6, 2021 at 4:12 PM Balazs Gibizer > wrote: >> >> >> On Mon, Sep 6, 2021 at 14:02, open infra >> wrote: >> > Hi, >> > >> > How to create a flavor with GPU? >> This document helps with the vGPU support in nova: >> https://docs.openstack.org/nova/latest/admin/virtual-gpu.html >> >> If you need a whole physical GPU to be passed to the guest instead >> then >> you can pass that through as a PCI device. Documented here: >> https://docs.openstack.org/nova/latest/admin/pci-passthrough.html >> >> Cheers, >> gibi >> >> > The way we set vcpu and memory. >> > >> > Regards, >> > Danishka >> >> From manchandavishal143 at gmail.com Mon Sep 6 11:00:02 2021 From: manchandavishal143 at gmail.com (vishal manchanda) Date: Mon, 6 Sep 2021 16:30:02 +0530 Subject: [horizon] Support for Django 3.x In-Reply-To: References: Message-ID: Hi Thomas, Horizon team working on adding django3.x support in horizon. A series of patches to add django3.x support is already up [1] and We recently merged a non-voting job to test django3.x which is failing right now[2]. The main issue we are facing in migration to django3.x is horizon using django-pyscss which isn't compatible with django3.x although we have some workaround to fix it[3] but it is not the right way. So I tried to contact the django-pyscss maintainer, but they didn't respond. Then we plan to use an alternative of django-pyscss i.e. django-sass-processor. Update on django-sass-processor: Me and radomir from horizon team worked on adding django-sass-processor support in horizon[4]. As far our testing it works fine with horizon but horizon default theme doesn't work with it right now and fails with error[5]. I am working on this issue, any help is really appreciated. [1] https://review.opendev.org/q/topic:%22django3-support%22+(status:open%20OR%20status:merged) [2] https://review.opendev.org/c/openstack/horizon/+/777390 [3] https://review.opendev.org/c/openstack/horizon/+/777391/ [4] https://review.opendev.org/c/openstack/horizon/+/794809 [5] https://paste.opendev.org/show/808595/ Thanks & Regards, Vishal Manchanda On Mon, Sep 6, 2021 at 1:06 PM Thomas Goirand wrote: > Hi, > > It's been a long time that Django 3.x is around, and therefore, it'd be > nice if Horizon had some kind of support for it. Indeed, sooner or > later, Django 3.x will be uploaded to Debian unstable. That day, I hope > Horizon doesn't just break. > > So, what's the status? Is anyone is at least working on it? > > Cheers, > > Thomas Goirand (zigo) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpantano at redhat.com Mon Sep 6 11:01:20 2021 From: fpantano at redhat.com (Francesco Pantano) Date: Mon, 6 Sep 2021 13:01:20 +0200 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: Hello, not sure this helps for your configuration but we used to support this scenario with TripleO [1]. The scenario is related to an external Ceph cluster deployed via ceph-ansible (or any other Ceph related tool) and consumed by some OSP services. In particular you can configure an external Swift (or Ceph RadosGW) proxy, and you can probably refer to the doc [1] to double check the parameters (in terms of endpoints and other configs) on both OSP and ceph side. Also, make sure the openstack user you're using to issue the "swift stat" command has the right roles assigned (the same accepted by RGW and defined in the ceph config). [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/swift_external.html On Mon, Sep 6, 2021 at 11:40 AM Michel Niyoyita wrote: > Hello, > > I am trying to replace swift by RGW as backend storage but I failed once I > try to post a container in the OpenStack side however, all interfaces are > configured (admin, public and internal). but Once I post from RGW host it > is created . Another issue is that object storage does not appear on the > horizon dashboard . I have deployed openstack all-in-one using > kolla-ansible and Os is ubuntu > > (kolla-open1) stack at kolla-open1:~$ swift -v post myswift > Container POST failed: http://ceph-osd3:8080/swift/v1/myswift 401 > Unauthorized b'AccessDenied' > Failed Transaction ID: tx000000000000000000008-006135dcbd-87d63-default > > (kolla-open1) stack at kolla-open1:~$ swift list > Account GET failed: http://ceph-osd3:8080/swift/v1?format=json 401 > Unauthorized [first 60 chars of response] > b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000c-' > Failed Transaction ID: tx00000000000000000000c-006135de42-87d63-default > > Kindly help to solve the issue > > Michel > > On Thu, Sep 2, 2021 at 4:28 PM Alex Schultz wrote: > >> The swift docs are a bit out of date as they still reference python2 >> despite python3 being supported for some time now. Replace python- with >> python3- and try again. >> >> >> On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita wrote: >> >>> >>> >>> ---------- Forwarded message --------- >>> From: Michel Niyoyita >>> Date: Thu, Sep 2, 2021 at 12:17 PM >>> Subject: Fwd: [ceph-users] Re: Replacing swift with RGW >>> To: >>> >>> >>> >>> >>> ---------- Forwarded message --------- >>> From: Eugen Block >>> Date: Thu, Sep 2, 2021 at 10:39 AM >>> Subject: Re: [ceph-users] Re: Replacing swift with RGW >>> To: Michel Niyoyita >>> >>> >>> You should continue this thread on the openstack-discuss mailing list >>> (openstack-discuss at lists.openstack.org) since this is not a ceph issue. >>> I'm not familiar with kolla and I don't know the requirements to >>> install openstack-swift, you'll need to ask the openstack community. >>> >>> >>> Zitat von Michel Niyoyita : >>> >>> > Below are errors I am getting once I try to run swift commands . the >>> second >>> > one is the error I get once try to install python-swiftclient >>> > >>> > (kolla-open) [stack at kolla-open ~]$ swift -v stat >>> > -bash: swift: command not found >>> > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install >>> python-swiftclient >>> > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 >>> 09:21:53 AM >>> > CAT. >>> > No match for argument: python-swiftclient >>> > Error: Unable to find a match: python-swiftclient >>> > (kolla-open) [stack at kolla-open ~]$ >>> > >>> > Waiting for your help >>> > >>> > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: >>> > >>> >> I can't tell for sure, but yes, I believe you need the openstack-swift >>> >> package (with dependencies). What errors do you get? The more >>> >> information you share the better people can help. >>> >> >>> >> >>> >> Zitat von Michel Niyoyita : >>> >> >>> >> > I tried to install "sudo yum -y install python-swiftclient" on >>> openstack >>> >> > side but fails . are there openastack-shwift packages which are >>> needed? >>> >> > if are there please help me to get . may be also it is the cause I >>> am >>> >> > failing to run swift command on openstack cli side. >>> >> > >>> >> > thank you for your continued support. >>> >> > >>> >> > Micheal >>> >> > >>> >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >>> >> > >>> >> >> I only configured the endpoints for the clients to directly access >>> the >>> >> >> RGWs, but you'll probably need to install the openstack-swift >>> package. >>> >> >> Or have you done that already? >>> >> >> >>> >> >> >>> >> >> Zitat von Michel Niyoyita : >>> >> >> >>> >> >> > Thank you Eugen for your prompt response. >>> >> >> > >>> >> >> > Now the commands provided work. but I am not finding the object >>> >> storage >>> >> >> on >>> >> >> > the horizon dashboard , but it appears in the system information >>> >> >> services. >>> >> >> > [image: image.png] >>> >> >> > so my question is how to configure it in order that it can >>> appear in >>> >> the >>> >> >> > dashboard . >>> >> >> > >>> >> >> > Michel >>> >> >> > >>> >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block >>> wrote: >>> >> >> > >>> >> >> >> Sorry, one little detail slipped through, the '--region' flag >>> has to >>> >> >> >> be put before the 'service' name. The correct command would be: >>> >> >> >> >>> >> >> >> openstack endpoint create --region RegionOne swift admin >>> >> >> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> >>> >> >> >> and respectively for the other interfaces. >>> >> >> >> >>> >> >> >> >>> >> >> >> Zitat von Eugen Block : >>> >> >> >> >>> >> >> >> > Hi, >>> >> >> >> > >>> >> >> >> > this is not a ceph issue but your openstack cli command as the >>> >> error >>> >> >> >> > message states. >>> >> >> >> > >>> >> >> >> > Try one interface at a time: >>> >> >> >> > >>> >> >> >> > openstack endpoint create swift public >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >>> >> >> >> > openstack endpoint create swift admin >>> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> > --region RegionOne swift >>> >> >> >> > openstack endpoint create swift internal >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > Zitat von Michel Niyoyita : >>> >> >> >> > >>> >> >> >> >> Hello , >>> >> >> >> >> >>> >> >> >> >> Below are errors I am getting once I am trying to integrate >>> swift >>> >> >> with >>> >> >> >> >> Radosgateway. >>> >> >> >> >> >>> >> >> >> >> From openstack side once i try to endpoint which will point >>> to the >>> >> >> >> >> radosgateway : >>> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint >>> create >>> >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >>> >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >>> >> >> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> >> --region RegionOne swift >>> >> >> >> >> usage: openstack endpoint create [-h] [-f >>> >> >> {json,shell,table,value,yaml}] >>> >> >> >> >> [-c COLUMN] [--noindent] >>> [--prefix >>> >> >> >> PREFIX] >>> >> >> >> >> [--max-width ] >>> >> [--fit-width] >>> >> >> >> >> [--print-empty] [--region >>> >> >> ] >>> >> >> >> >> [--enable | --disable] >>> >> >> >> >> >>> >> >> >> >> openstack endpoint create: error: argument : >>> invalid >>> >> >> choice: >>> >> >> >> ' >>> >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', >>> 'public', >>> >> >> >> 'internal') >>> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >>> >> >> >> >> >>> >> >> >> >> below are my /etc/ceph/ceph.conf file : >>> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3] >>> >> >> >> >> rgw_dns_name = ceph-osd3 >>> >> >> >> >> host = ceph-osd3 >>> >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >>> >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 >>> num_threads=100 >>> >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >>> >> >> >> >> rgw_keystone_admin_user=admin >>> >> >> >> >> rgw_keystone_admin_password=admin >>> >> >> >> >> rgw_keystone_admin_tenant=admin >>> >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >>> >> >> >> >> rgw_keystone_token_cache_size=200 >>> >> >> >> >> rgw_keystone_revocation_interval=300 >>> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >>> >> >> >> >> host = ceph-osd3 >>> >> >> >> >> keyring = >>> /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >>> >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >>> >> >> >> >> rgw thread pool size = 512 >>> >> >> >> >> >>> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with >>> 10.10.29.110 as >>> >> IP >>> >> >> >> >> >>> >> >> >> >> and 10.10.29.150 all-in-one IP >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> Please crosscheck where I might make mistake and try to >>> correct. >>> >> >> >> >> >>> >> >> >> >> Best regards >>> >> >> >> >> >>> >> >> >> >> Michel >>> >> >> >> >> >>> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >>> >> >> >> etienne.menguy at croit.io> >>> >> >> >> >> wrote: >>> >> >> >> >> >>> >> >> >> >>> Hi, >>> >> >> >> >>> >>> >> >> >> >>> There are some information on Ceph documentation >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >>> >> >> >> >>> - Use keystone as auth for RGW >>> >> >> >> >>> - Create service and register your RGW as swift >>> >> >> >> >>> >>> >> >> >> >>> Étienne >>> >> >> >> >>> >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita < >>> micou12 at gmail.com> >>> >> >> wrote: >>> >> >> >> >>>> >>> >> >> >> >>>> Hello , >>> >> >> >> >>>> >>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using >>> ceph >>> >> >> ansible >>> >> >> >> and >>> >> >> >> >>>> create sub user to access the created containers and would >>> like >>> >> to >>> >> >> >> >>> replace >>> >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >>> >> >> configuration >>> >> >> >> to >>> >> >> >> >>> be >>> >> >> >> >>>> done in the OpenStack side in order to integrate those >>> >> services. I >>> >> >> >> have >>> >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu >>> 20.04. >>> >> and >>> >> >> >> ceph >>> >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >>> >> >> >> >>>> >>> >> >> >> >>>> Kindly help for the configuration or documentation. >>> >> >> >> >>>> >>> >> >> >> >>>> Best Regards >>> >> >> >> >>>> >>> >> >> >> >>>> Michel >>> >> >> >> >>>> _______________________________________________ >>> >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >>> >> >> >> >>> _______________________________________________ >>> >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >>> >> >> >> >> _______________________________________________ >>> >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> _______________________________________________ >>> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Mon Sep 6 11:20:45 2021 From: tonykarera at gmail.com (Karera Tony) Date: Mon, 6 Sep 2021 13:20:45 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello Maysa, There is no process running on port 8080 and yes I have configured kuryr Regards Tony Karera On Mon, Sep 6, 2021 at 10:17 AM Maysa De Macedo Souza wrote: > Hello, > > Just some extra thought, did you check if there is some process running on > port 8080? It's possible that the API failed to start, is Kuryr being used? > > Thanks, > Maysa Macedo. > > On Tue, Aug 31, 2021 at 1:57 PM Karera Tony wrote: > >> 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 josephine.seifert at secustack.com Mon Sep 6 11:25:28 2021 From: josephine.seifert at secustack.com (Josephine Seifert) Date: Mon, 6 Sep 2021 13:25:28 +0200 Subject: [Image Encryption] Next Meeting on Monday 13 Message-ID: Hi everyone, as I am on vacation the next meeting will be next monday - the 13th of September. greetings Josephine (Luzi) From wilrichard00 at gmail.com Mon Sep 6 12:22:29 2021 From: wilrichard00 at gmail.com (Jean Richard) Date: Mon, 6 Sep 2021 08:22:29 -0400 Subject: [Neutron] [Kolla ansible ] external network setting for vlan In-Reply-To: References: Message-ID: Hi Rahul, I am new to Openstack. I have been trying to deploy Devstack (not much success) for practice and later Kolla Ansible All-in-one (again not much success). Can you please share your configuration file for deploying the Wallaby release? Thank you very much. Best regards, Jean Richard On Mon, Sep 6, 2021 at 3:09 AM Lajos Katona wrote: > Hi Rahul, > Not sure where You started your research so I add some basic documentation > (but it has links to further docs): > > - Openstack Networking concepts: > https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html > - Deployment with OVS (not sure which mechanism driver You use): > https://docs.openstack.org/neutron/latest/admin/deploy-ovs.html > - here You can find config and CLI examples if You open the links. > > Lajos (lajoskatona) > > > Rahul Miragi <22rahulmiragi at gmail.com> ezt írta (időpont: 2021. szept. > 3., P, 21:46): > >> Hi team, >> >> I am using kolla ansible to deploy wallaby release on single node. I have >> successfully deployed it and now I want to create external network and >> attach external IPs to openstack VMs. But somehow I’m unable to configure >> it. Could you please share some articles or config examples. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From geguileo at redhat.com Mon Sep 6 13:28:13 2021 From: geguileo at redhat.com (Gorka Eguileor) Date: Mon, 6 Sep 2021 15:28:13 +0200 Subject: [dev][cinder] Consultation about new cinder-backup features In-Reply-To: References: Message-ID: <20210906132813.xsaxbsyyvf4ey4vm@localhost> On 27/08, Daniel de Oliveira Pereira 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. Hi Daniel, Thank you very much for your willingness to give back!!! > > 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. This is a feature that has been discussed before, and e0ne already did some of the prerequisites for it. > 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. > What about the username and password? Can backups be restored from a remote location as well? This sounds like a very cool feature, but I'm not too comfortable with having it in Cinder. The idea is that Cinder provides an abstraction and doesn't let users know about implementation details. With that feature as it is a user could request a backup to an off-site location that could result in congestion in one of the outbound connections. I can only think of this being acceptable for admin users, and in that case I think it would be best to use the multi-backup destination feature instead. After all, how many times do we have to backup to a different location? Maybe I'm missing a use case. If the community thinks this as a desired feature I would encourage adding it with a policy that disables it by default. > 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. > When this feature was discussed upstream we liked the idea of implementing this like we do multi-backends for the volume service, adding backup-types. In latest code backup creation operations have been modified to go through the scheduler, so that's a piece that is already implemented. > 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 > I believe you will have the full community's support on the first idea (though probably not on the proposed implementation). I'm not so sure on the second one, iti will most likely depend on the use cases. Many times the reasons why features are dismissed upstream is because there are no clear use cases that justify the addition of the code. Looking forward to continuing this conversation at the PTG, IRC, in a spec, or through here. Cheers, Gorka. From zhangbailin at inspur.com Mon Sep 6 14:06:23 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Mon, 6 Sep 2021 14:06:23 +0000 Subject: =?gb2312?B?u9i4tKO6W2xpc3RzLm9wZW5zdGFjay5vcme0+reiXWZsYXZvciB3aXRoIEdQ?= =?gb2312?Q?U?= In-Reply-To: References: , Message-ID: If you deployed Cyborg on you environment, you can create a device_profile with GPU(openstack device profile create …)，then add the metadata of device_profile:GPU in the flavor，then you can boot an instance with this flavor，it will be done by nova and cyborg. Below [1] is the SSD supported test that you can refer, the GPU test report we will plan to add in Yoga release. [1]https://wiki.openstack.org/wiki/Cyborg/TestReport/InspurFPGA -------- 原始邮件 -------- 发件人： open infra 日期： 2021年9月6日周一 16:37 收件人： openstack-discuss 主 题： [lists.openstack.org代发]flavor with GPU Hi, How to create a flavor with GPU? The way we set vcpu and memory. Regards, Danishka From tonykarera at gmail.com Mon Sep 6 14:26:56 2021 From: tonykarera at gmail.com (Karera Tony) Date: Mon, 6 Sep 2021 16:26:56 +0200 Subject: Octavia Issues Message-ID: Dear Team, I have openstack wallaby running on Ubuntu deployed using kolla-ansible but whenever I create a load balancer I get the error below in the octavia-worker.log octavia.common.exceptions.ComputeBuildException: Failed to build compute instance due to: Failed to retrieve 2021-09-06 14:14:49.392 20 ERROR oslo_messaging.rpc.server But I have an image with the correct tag as shown below. (kolla-openstack) stack at deployment:~$ openstack image show amphora1 | grep tag | tags | amphora Kindly advise if I am missing anything. Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Mon Sep 6 14:44:01 2021 From: eblock at nde.ag (Eugen Block) Date: Mon, 06 Sep 2021 14:44:01 +0000 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> Message-ID: <20210906144401.Horde.7j4UyxpB4wl0f5RgwX1Y0FD@webmail.nde.ag> It's hard to tell what is wrong with your setup, I don't really use mine but this was the last working config I had to be able to create swift containers directly in RGW: ---snip--- # ceph.conf: [client.rgw.ses6-mon1] rgw frontends = "beast port=80" rgw dns name = ses6-mon1.example.com rgw enable usage log = true rgw thread pool size = 512 rgw keystone api version = 3 rgw keystone url = http://control-node.example.com:5000 rgw keystone admin user = rgw rgw keystone admin password = **** rgw keystone admin domain = default rgw keystone admin project = service rgw keystone accepted roles = admin,Member,_member_,member rgw keystone verify ssl = false rgw s3 auth use keystone = true rgw keystone revocation interval = 0 # User role (I don't think admin is required) openstack role add --user rgw --project 9e8a67da237a4b26afb2819d2dea2219 admin # Create keystone endpoints openstack endpoint create --region RegionOne swift admin "http://ses6-mon1.example.com:80/swift/v1" openstack endpoint create --region RegionOne swift internal "http://ses6-mon1.example.com:80/swift/v1" openstack endpoint create --region RegionOne swift public "http://ses6-mon1.example.com:80/swift/v1" # Create container and files openstack container create swift1 +---------+-----------+---------------------------------------------------+ | account | container | x-trans-id | +---------+-----------+---------------------------------------------------+ | v1 | swift1 | tx000000000000000000001-0060b4ba48-d724dc-default | +---------+-----------+---------------------------------------------------+ openstack object create --name file1 swift1 chef-client.log +--------+-----------+----------------------------------+ | object | container | etag | +--------+-----------+----------------------------------+ | file1 | swift1 | 56a1ed3b201c1e753bcbe80c640349f7 | +--------+-----------+----------------------------------+ ---snip--- You are mixing dns names and IP addresses, I can't tell if that's a problem but it probably should work, I'm not sure. Compared to my ceph.conf these are the major differences: rgw keystone verify ssl = false rgw s3 auth use keystone = true rgw keystone revocation interval = 0 And I don't use rgw_keystone_token_cache_size. Maybe try again with the options I use. Zitat von Michel Niyoyita : > Hello, > > I am trying to replace swift by RGW as backend storage but I failed once I > try to post a container in the OpenStack side however, all interfaces are > configured (admin, public and internal). but Once I post from RGW host it > is created . Another issue is that object storage does not appear on the > horizon dashboard . I have deployed openstack all-in-one using > kolla-ansible and Os is ubuntu > > (kolla-open1) stack at kolla-open1:~$ swift -v post myswift > Container POST failed: http://ceph-osd3:8080/swift/v1/myswift 401 > Unauthorized b'AccessDenied' > Failed Transaction ID: tx000000000000000000008-006135dcbd-87d63-default > > (kolla-open1) stack at kolla-open1:~$ swift list > Account GET failed: http://ceph-osd3:8080/swift/v1?format=json 401 > Unauthorized [first 60 chars of response] > b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000c-' > Failed Transaction ID: tx00000000000000000000c-006135de42-87d63-default > > Kindly help to solve the issue > > Michel > > On Thu, Sep 2, 2021 at 4:28 PM Alex Schultz wrote: > >> The swift docs are a bit out of date as they still reference python2 >> despite python3 being supported for some time now. Replace python- with >> python3- and try again. >> >> >> On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita wrote: >> >>> >>> >>> ---------- Forwarded message --------- >>> From: Michel Niyoyita >>> Date: Thu, Sep 2, 2021 at 12:17 PM >>> Subject: Fwd: [ceph-users] Re: Replacing swift with RGW >>> To: >>> >>> >>> >>> >>> ---------- Forwarded message --------- >>> From: Eugen Block >>> Date: Thu, Sep 2, 2021 at 10:39 AM >>> Subject: Re: [ceph-users] Re: Replacing swift with RGW >>> To: Michel Niyoyita >>> >>> >>> You should continue this thread on the openstack-discuss mailing list >>> (openstack-discuss at lists.openstack.org) since this is not a ceph issue. >>> I'm not familiar with kolla and I don't know the requirements to >>> install openstack-swift, you'll need to ask the openstack community. >>> >>> >>> Zitat von Michel Niyoyita : >>> >>> > Below are errors I am getting once I try to run swift commands . the >>> second >>> > one is the error I get once try to install python-swiftclient >>> > >>> > (kolla-open) [stack at kolla-open ~]$ swift -v stat >>> > -bash: swift: command not found >>> > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install >>> python-swiftclient >>> > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 09:21:53 >>> AM >>> > CAT. >>> > No match for argument: python-swiftclient >>> > Error: Unable to find a match: python-swiftclient >>> > (kolla-open) [stack at kolla-open ~]$ >>> > >>> > Waiting for your help >>> > >>> > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: >>> > >>> >> I can't tell for sure, but yes, I believe you need the openstack-swift >>> >> package (with dependencies). What errors do you get? The more >>> >> information you share the better people can help. >>> >> >>> >> >>> >> Zitat von Michel Niyoyita : >>> >> >>> >> > I tried to install "sudo yum -y install python-swiftclient" on >>> openstack >>> >> > side but fails . are there openastack-shwift packages which are >>> needed? >>> >> > if are there please help me to get . may be also it is the cause I >>> am >>> >> > failing to run swift command on openstack cli side. >>> >> > >>> >> > thank you for your continued support. >>> >> > >>> >> > Micheal >>> >> > >>> >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >>> >> > >>> >> >> I only configured the endpoints for the clients to directly access >>> the >>> >> >> RGWs, but you'll probably need to install the openstack-swift >>> package. >>> >> >> Or have you done that already? >>> >> >> >>> >> >> >>> >> >> Zitat von Michel Niyoyita : >>> >> >> >>> >> >> > Thank you Eugen for your prompt response. >>> >> >> > >>> >> >> > Now the commands provided work. but I am not finding the object >>> >> storage >>> >> >> on >>> >> >> > the horizon dashboard , but it appears in the system information >>> >> >> services. >>> >> >> > [image: image.png] >>> >> >> > so my question is how to configure it in order that it can appear >>> in >>> >> the >>> >> >> > dashboard . >>> >> >> > >>> >> >> > Michel >>> >> >> > >>> >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block wrote: >>> >> >> > >>> >> >> >> Sorry, one little detail slipped through, the '--region' flag >>> has to >>> >> >> >> be put before the 'service' name. The correct command would be: >>> >> >> >> >>> >> >> >> openstack endpoint create --region RegionOne swift admin >>> >> >> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> >>> >> >> >> and respectively for the other interfaces. >>> >> >> >> >>> >> >> >> >>> >> >> >> Zitat von Eugen Block : >>> >> >> >> >>> >> >> >> > Hi, >>> >> >> >> > >>> >> >> >> > this is not a ceph issue but your openstack cli command as the >>> >> error >>> >> >> >> > message states. >>> >> >> >> > >>> >> >> >> > Try one interface at a time: >>> >> >> >> > >>> >> >> >> > openstack endpoint create swift public >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >>> >> >> >> > openstack endpoint create swift admin >>> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> > --region RegionOne swift >>> >> >> >> > openstack endpoint create swift internal >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > Zitat von Michel Niyoyita : >>> >> >> >> > >>> >> >> >> >> Hello , >>> >> >> >> >> >>> >> >> >> >> Below are errors I am getting once I am trying to integrate >>> swift >>> >> >> with >>> >> >> >> >> Radosgateway. >>> >> >> >> >> >>> >> >> >> >> From openstack side once i try to endpoint which will point >>> to the >>> >> >> >> >> radosgateway : >>> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint >>> create >>> >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >>> >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >>> >> >> >> http://ceph-osd3:8080/swift/v1 >>> >> >> >> >> --region RegionOne swift >>> >> >> >> >> usage: openstack endpoint create [-h] [-f >>> >> >> {json,shell,table,value,yaml}] >>> >> >> >> >> [-c COLUMN] [--noindent] >>> [--prefix >>> >> >> >> PREFIX] >>> >> >> >> >> [--max-width ] >>> >> [--fit-width] >>> >> >> >> >> [--print-empty] [--region >>> >> >> ] >>> >> >> >> >> [--enable | --disable] >>> >> >> >> >> >>> >> >> >> >> openstack endpoint create: error: argument : >>> invalid >>> >> >> choice: >>> >> >> >> ' >>> >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', >>> 'public', >>> >> >> >> 'internal') >>> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >>> >> >> >> >> >>> >> >> >> >> below are my /etc/ceph/ceph.conf file : >>> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3] >>> >> >> >> >> rgw_dns_name = ceph-osd3 >>> >> >> >> >> host = ceph-osd3 >>> >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >>> >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 >>> num_threads=100 >>> >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >>> >> >> >> >> rgw_keystone_admin_user=admin >>> >> >> >> >> rgw_keystone_admin_password=admin >>> >> >> >> >> rgw_keystone_admin_tenant=admin >>> >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >>> >> >> >> >> rgw_keystone_token_cache_size=200 >>> >> >> >> >> rgw_keystone_revocation_interval=300 >>> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >>> >> >> >> >> host = ceph-osd3 >>> >> >> >> >> keyring = >>> /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >>> >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >>> >> >> >> >> rgw thread pool size = 512 >>> >> >> >> >> >>> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with >>> 10.10.29.110 as >>> >> IP >>> >> >> >> >> >>> >> >> >> >> and 10.10.29.150 all-in-one IP >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> Please crosscheck where I might make mistake and try to >>> correct. >>> >> >> >> >> >>> >> >> >> >> Best regards >>> >> >> >> >> >>> >> >> >> >> Michel >>> >> >> >> >> >>> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >>> >> >> >> etienne.menguy at croit.io> >>> >> >> >> >> wrote: >>> >> >> >> >> >>> >> >> >> >>> Hi, >>> >> >> >> >>> >>> >> >> >> >>> There are some information on Ceph documentation >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >>> >> >> >> >>> - Use keystone as auth for RGW >>> >> >> >> >>> - Create service and register your RGW as swift >>> >> >> >> >>> >>> >> >> >> >>> Étienne >>> >> >> >> >>> >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita < >>> micou12 at gmail.com> >>> >> >> wrote: >>> >> >> >> >>>> >>> >> >> >> >>>> Hello , >>> >> >> >> >>>> >>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using ceph >>> >> >> ansible >>> >> >> >> and >>> >> >> >> >>>> create sub user to access the created containers and would >>> like >>> >> to >>> >> >> >> >>> replace >>> >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >>> >> >> configuration >>> >> >> >> to >>> >> >> >> >>> be >>> >> >> >> >>>> done in the OpenStack side in order to integrate those >>> >> services. I >>> >> >> >> have >>> >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu >>> 20.04. >>> >> and >>> >> >> >> ceph >>> >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >>> >> >> >> >>>> >>> >> >> >> >>>> Kindly help for the configuration or documentation. >>> >> >> >> >>>> >>> >> >> >> >>>> Best Regards >>> >> >> >> >>>> >>> >> >> >> >>>> Michel >>> >> >> >> >>>> _______________________________________________ >>> >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >>> >> >> >> >>> _______________________________________________ >>> >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >>> >> >> >> >> _______________________________________________ >>> >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> _______________________________________________ >>> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >>> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >>> >> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> From balazs.gibizer at est.tech Mon Sep 6 14:52:09 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 06 Sep 2021 16:52:09 +0200 Subject: [placement][requirements] RFE requested for osc-placement lib Message-ID: Dear Release Team, The recently released osc-placement 3.1.0 has a serious bug[1] causing placement related openstack CLI commands to fail. The bugfix has been merged[2]. And a new bugfix release is proposed for osc-placement[3]. Please consider accepting this freeze exceptionm Thanks! gibi [1] https://bugs.launchpad.net/placement-osc-plugin/+bug/1942740 [2] https://review.opendev.org/c/openstack/osc-placement/+/807556 [3] https://review.opendev.org/c/openstack/releases/+/807591 From tkajinam at redhat.com Mon Sep 6 14:53:06 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Mon, 6 Sep 2021 23:53:06 +0900 Subject: [puppet] Propose retiring puppet-freezer Message-ID: Hello, Today I looked into the current code of puppet-freezer and noticed this module is still very incomplete. Most of its implementations are inherited from the cookiecutter template, and the module doesn't support fundamental resources like packages, services and so on. Because we haven't seen any interest in fixing that feature gap for a long time, I'll propose retiring the module during this cycle. Please let me know if you have any concerns. If I don't hear any objections I'll submit a series of patches to retire the module. Thank you, Takashi Kajinami -------------- next part -------------- An HTML attachment was scrubbed... URL: From gthiemonge at redhat.com Mon Sep 6 15:14:08 2021 From: gthiemonge at redhat.com (Gregory Thiemonge) Date: Mon, 6 Sep 2021 17:14:08 +0200 Subject: Octavia Issues In-Reply-To: References: Message-ID: Hi Tony, I think the log line is truncated, do you have more information in the logs? If it is related to the amphora image, you also need to ensure that the owner of the image in glance is the same project as defined in the [controller_worker]/amp_image_owner_id config option in octavia.conf (it is the id of the admin project in devstack for instance) Greg On Mon, Sep 6, 2021 at 4:31 PM Karera Tony wrote: > Dear Team, > > I have openstack wallaby running on Ubuntu deployed using kolla-ansible > but whenever I create a load balancer I get the error below in the > octavia-worker.log > > octavia.common.exceptions.ComputeBuildException: Failed to build compute > instance due to: Failed to retrieve > 2021-09-06 14:14:49.392 20 ERROR oslo_messaging.rpc.server > > But I have an image with the correct tag as shown below. > > (kolla-openstack) stack at deployment:~$ openstack image show amphora1 | > grep tag > | tags | amphora > > Kindly advise if I am missing anything. > > Regards > > Tony Karera > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Mon Sep 6 15:18:51 2021 From: mthode at mthode.org (Matthew Thode) Date: Mon, 6 Sep 2021 10:18:51 -0500 Subject: [placement][requirements] RFE requested for osc-placement lib In-Reply-To: References: Message-ID: <20210906151851.ky3clilvzcggk4zt@mthode.org> On 21-09-06 16:52:09, Balazs Gibizer wrote: > Dear Release Team, > > The recently released osc-placement 3.1.0 has a serious bug[1] causing > placement related openstack CLI commands to fail. The bugfix has been > merged[2]. And a new bugfix release is proposed for osc-placement[3]. Please > consider accepting this freeze exceptionm > > Thanks! > gibi > > [1] https://bugs.launchpad.net/placement-osc-plugin/+bug/1942740 > [2] https://review.opendev.org/c/openstack/osc-placement/+/807556 > [3] https://review.opendev.org/c/openstack/releases/+/807591 > > > Sounds good (freeze excepted) -- 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 wodel.youchi at gmail.com Mon Sep 6 15:37:16 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 6 Sep 2021 16:37:16 +0100 Subject: Ceph dashboard HCI deployment Message-ID: Hi, I deployed Openstack Train using TripleO, I added ceph dashboard template to my deployment. But it is not reachable via the provisioning network, it is reachable via the storage network. Is this the default behavior? Did I miss something? I modified the haproxy configuration to point the dashboard to the ctplane vip address and it worked. How do I make this work from the deployment? Could an update of the overcloud, reset the configuration of the haproxy to the default? Thanks in advance. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdemaced at redhat.com Mon Sep 6 15:52:16 2021 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Mon, 6 Sep 2021 17:52:16 +0200 Subject: Changing Magnum Heat template to create node network with vxlan instead of vlan In-Reply-To: References: Message-ID: Hello, Is it a development environment using devstack? You can check the status of the load-balancer API and the Kuryr container/service logs. You can also reach us at #openstack-kuryr channel. Cheers, Maysa. On Mon, Sep 6, 2021 at 1:21 PM Karera Tony wrote: > Hello Maysa, > > There is no process running on port 8080 and yes I have configured kuryr > Regards > > Tony Karera > > > > > On Mon, Sep 6, 2021 at 10:17 AM Maysa De Macedo Souza > wrote: > >> Hello, >> >> Just some extra thought, did you check if there is some process running >> on port 8080? It's possible that the API failed to start, is Kuryr being >> used? >> >> Thanks, >> Maysa Macedo. >> >> On Tue, Aug 31, 2021 at 1:57 PM Karera Tony wrote: >> >>> 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 ssbarnea at redhat.com Mon Sep 6 16:32:50 2021 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 6 Sep 2021 09:32:50 -0700 Subject: goodbye openstack, welcome ansible Message-ID: Today was my last day as a part of the OpenStack team at Red Hat. After almost 5 years, I've decided to use the opportunity to join the newly created Ansible DevTools team, a team that will improve and maintain development tools such as ansible-lint, molecule and the more recent Ansible extension for VS Code. If you are interested in finding out more, make sure to attend the next Ansible Contributor Summit which is happening at the end of this month. To those who will be missing me, don't worry I will not be far away. Cheers! Sorin Sbarnea -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlandy at redhat.com Mon Sep 6 16:47:22 2021 From: rlandy at redhat.com (Ronelle Landy) Date: Mon, 6 Sep 2021 12:47:22 -0400 Subject: goodbye openstack, welcome ansible In-Reply-To: References: Message-ID: Sorin, thank you for all you contributed. We will miss you - especially on the TripleO CI team. Best of luck in our new role! On Mon, Sep 6, 2021 at 12:37 PM Sorin Sbarnea wrote: > Today was my last day as a part of the OpenStack team at Red Hat. After > almost 5 years, I've decided to use the opportunity to join the newly > created Ansible DevTools team, a team that will improve and maintain > development tools such as ansible-lint, molecule and the more recent > Ansible extension for VS Code. > > If you are interested in finding out more, make sure to attend the next Ansible > Contributor Summit > which is > happening at the end of this month. > > To those who will be missing me, don't worry I will not be far away. > > Cheers! > Sorin Sbarnea > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpantano at redhat.com Mon Sep 6 16:49:18 2021 From: fpantano at redhat.com (Francesco Pantano) Date: Mon, 6 Sep 2021 18:49:18 +0200 Subject: Ceph dashboard HCI deployment In-Reply-To: References: Message-ID: Hello, Thanks for looking into this. I think the problem you found on the haproxy config for the Ceph Dashboard is related to [1], where is given to the operator the flexibility of moving the ceph dashboard haproxy frontend vip on a network != ctlplane when no CephStorageDashboard composable network is defined [2]. On Mon, Sep 6, 2021 at 5:42 PM wodel youchi wrote: > Hi, > > I deployed Openstack Train using TripleO, I added ceph dashboard template > to my deployment. But it is not reachable via the provisioning network, it > is reachable via the storage network. Is this the default behavior? Did I > miss something? > > I modified the haproxy configuration to point the dashboard to the ctplane > vip address and it worked. > > How do I make this work from the deployment? > You can do that by overriding the CephDashboardNetwork parameter, which means you can add to your existing deployed *CephDashboardNetwork:ctlplane * By doing this, during the next stack update the haproxy config that points to the ctlplane network should be maintained. > > Could an update of the overcloud, reset the configuration of the haproxy to > the default? > Exactly, a stack update will result in applying the default values defined in your tht. For this reason, you should pass CephDashboardNetwork:ctlplane to your overcloud deploy. > > Thanks in advance. Regards. > I started a patch series [3] to make sure the Ceph Dashboard network uses the right networks, maintaining the ability to change it overriding the parameter described above. Thank you!! [1] https://review.opendev.org/c/openstack/tripleo-ansible/+/801757 [2] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/ceph_config.html#adding-ceph-dashboard-to-a-overcloud-deployment [3] https://review.opendev.org/q/topic:%22ceph_dashboard_network%22+(status:open%20OR%20status:merged) -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Sep 6 17:35:04 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 06 Sep 2021 12:35:04 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Sept 9th at 1500 UTC Message-ID: <17bbc2d846e.11adf55c390492.8839891819324332226@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Sept 9th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Sept 8th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From kazumasa.nomura.rx at hitachi.com Mon Sep 6 18:48:09 2021 From: kazumasa.nomura.rx at hitachi.com (=?utf-8?B?6YeO5p2R5ZKM5q2jIC8gTk9NVVJB77yMS0FaVU1BU0E=?=) Date: Mon, 6 Sep 2021 18:48:09 +0000 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: Hi Team, I'd like to request FFE to the following change: [1] Hitachi: Add generic volume groups https://review.opendev.org/c/openstack/cinder/+/782910 - This patch adds consistency group capability as generic volume groups for the Hitachi driver. This change and blueprint were submitted in time and it has been good progress in the reviews until this point. This patch is isolated to the Hitachi driver module, and have no impact on the Cinder database, REST/RPC and APIs. Kind Regards, Kazumasa Nomura -----Original Message----- From: Brian Rosmaita Sent: Saturday, September 4, 2021 5:55 AM To: openstack-discuss at lists.openstack.org Subject: [!][cinder] xena feature freeze The Xena feature freeze for cinder is now in effect. Please do not approve patches proposing features for master until after the stable/xena branch has been cut the week of 13 September. The following blueprints are granted feature freeze exceptions: - https://secure-web.cisco.com/1esUHJyUlDOFXd10REcKVNw8NBLq3WM7zB53bQ2dG6d_4AKYrcnDvITVjZOXPlqoguipoly92XJj_W3xyJJXJkN9lP27RobrMUbliwyUrQYv2w7pRlBj-ikdJiRK5Tgh4tKsxdNufvDl39xyiVWpPnc4cD4GnXKMObQBa5UHG__8gMhk4v3biFveL4uaBjziC5fw9mzI1hOZyvFBhR36p5TVR4FnPdZ9DQ0jOoJ_YGcfdTZNzaadIlYA9HaMPhIo0wYdpjxBEBI9DYd_4inMliFshH-dLz4OWtvsu9bH21lOoU994XxUpyizz45wdPY_W/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fs-rbac-ready-x - https://secure-web.cisco.com/1wxRMdxHHb-gemG2KizQtfPjVmtpBfsSPKKdJXHmCPFs6L9o7JMH8uHQahyjUFbqwMGZz_SG5lNgP-DwS5dojrm-h3OhiOJFW1sf2QDBsshmMAhfM5srV3EYjsrtR49oFwMWw-fpQiM9T0DNSebWXVa_RvoS0BFix9oEasQxVe445BuRf23R3Z5WJ4EnyS0LB-kS00pI4Wng4mIg9216x_2hL1Te3d2GvmYCOdoYKVKxuDi019xG8lR5OTZGRqfRzj7yBXwWYSJihXxn1YRIUegKHGfi5mhG9_Jy-p-qVJrd8PWrrWrr3oLuT8Gy6-5u5/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fremove-sqlalchemy-migrate Any other feature patches (including driver features) that have not yet merged and are associated with an approved xena blueprint may apply for a Feature Freeze Exception by replying to this email before Tuesday, 7 September at 20:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Xena. It is expected that patches granted an FFE will be merged by 21:00 UTC on Monday 13 September. Bugfixes do not require an FFE. To be included in Xena, they must be merged before the first Release Candidate is cut on Thursday 16 September. After that point, only release-critical bugfixes will be allowed into the Xena release. Ping me in IRC if you have any questions. cheers, brian From kazumasa.nomura.rx at hitachi.com Mon Sep 6 18:53:33 2021 From: kazumasa.nomura.rx at hitachi.com (=?utf-8?B?6YeO5p2R5ZKM5q2jIC8gTk9NVVJB77yMS0FaVU1BU0E=?=) Date: Mon, 6 Sep 2021 18:53:33 +0000 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: Hi Team, I'd like to request FFE to the following change: [1] Hitachi: Add generic volume groups https://review.opendev.org/c/openstack/cinder/+/782910 - This patch adds consistency group capability as generic volume groups for the Hitachi driver. This change and blueprint were submitted in time and it has been good progress in the reviews until this point. This patch is isolated to the Hitachi driver module, and have no impact on the Cinder database, REST/RPC and APIs. Kind Regards, Kazumasa Nomura -----Original Message----- From: Brian Rosmaita Sent: Saturday, September 4, 2021 5:55 AM To: openstack-discuss at lists.openstack.org Subject: [!][cinder] xena feature freeze The Xena feature freeze for cinder is now in effect. Please do not approve patches proposing features for master until after the stable/xena branch has been cut the week of 13 September. The following blueprints are granted feature freeze exceptions: - https://secure-web.cisco.com/1esUHJyUlDOFXd10REcKVNw8NBLq3WM7zB53bQ2dG6d_4AKYrcnDvITVjZOXPlqoguipoly92XJj_W3xyJJXJkN9lP27RobrMUbliwyUrQYv2w7pRlBj-ikdJiRK5Tgh4tKsxdNufvDl39xyiVWpPnc4cD4GnXKMObQBa5UHG__8gMhk4v3biFveL4uaBjziC5fw9mzI1hOZyvFBhR36p5TVR4FnPdZ9DQ0jOoJ_YGcfdTZNzaadIlYA9HaMPhIo0wYdpjxBEBI9DYd_4inMliFshH-dLz4OWtvsu9bH21lOoU994XxUpyizz45wdPY_W/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fs-rbac-ready-x - https://secure-web.cisco.com/1wxRMdxHHb-gemG2KizQtfPjVmtpBfsSPKKdJXHmCPFs6L9o7JMH8uHQahyjUFbqwMGZz_SG5lNgP-DwS5dojrm-h3OhiOJFW1sf2QDBsshmMAhfM5srV3EYjsrtR49oFwMWw-fpQiM9T0DNSebWXVa_RvoS0BFix9oEasQxVe445BuRf23R3Z5WJ4EnyS0LB-kS00pI4Wng4mIg9216x_2hL1Te3d2GvmYCOdoYKVKxuDi019xG8lR5OTZGRqfRzj7yBXwWYSJihXxn1YRIUegKHGfi5mhG9_Jy-p-qVJrd8PWrrWrr3oLuT8Gy6-5u5/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fremove-sqlalchemy-migrate Any other feature patches (including driver features) that have not yet merged and are associated with an approved xena blueprint may apply for a Feature Freeze Exception by replying to this email before Tuesday, 7 September at 20:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Xena. It is expected that patches granted an FFE will be merged by 21:00 UTC on Monday 13 September. Bugfixes do not require an FFE. To be included in Xena, they must be merged before the first Release Candidate is cut on Thursday 16 September. After that point, only release-critical bugfixes will be allowed into the Xena release. Ping me in IRC if you have any questions. cheers, brian From zigo at debian.org Mon Sep 6 19:29:01 2021 From: zigo at debian.org (Thomas Goirand) Date: Mon, 6 Sep 2021 21:29:01 +0200 Subject: [horizon] Support for Django 3.x In-Reply-To: References: Message-ID: <1977ce4f-bf9b-9a03-672d-b85531ea1187@debian.org> On 9/6/21 1:00 PM, vishal manchanda wrote: > Hi Thomas, > > Horizon team working on adding django3.x support in horizon. > A series of patches to add django3.x support is already up [1] and We > recently merged a non-voting job to test > django3.x which is failing right now[2]. The main issue we are facing in > migration to django3.x is horizon > using django-pyscss which isn't compatible with django3.x although we > have some workaround to fix it[3] > but it is not the right way. So I tried to contact the django-pyscss > maintainer, but they didn't respond. > Then we plan to use an alternative of django-pyscss i.e. > django-sass-processor. > > Update on django-sass-processor: Me and radomir from horizon team worked > on adding django-sass-processor > support in horizon[4]. As far our testing it works fine with horizon but > horizon default theme doesn't work with it  > right now and fails with error[5]. I am working on this issue, any help > is really appreciated. Hi Vishal, Thanks a lot for giving a status update, I'm very happy to see there's work toward Django 3.x support. Thanks to you and all the team. FYI, I unfortunately don't have the skills to help. However, I can work for having new dependencies available in Debian, and so also in Ubuntu. Do you think I should package django-sass-processor right now? Or is it too early to tell it's going to be the adopted solution? Cheers, Thomas Goirand (zigo) From berndbausch at gmail.com Tue Sep 7 02:59:01 2021 From: berndbausch at gmail.com (Bernd Bausch) Date: Tue, 7 Sep 2021 11:59:01 +0900 Subject: Does ceph and openstack communicate over the openstack-API network? In-Reply-To: References: Message-ID: Neither OpenStack nor Ceph prescribe which networks are used for which purpose. They communicate over the network that you set up and configure. On 2021/09/06 6:48 PM, wodel youchi wrote: > Hi, > > Does ceph and openstack communicate over the openstack-API network, > for nova, cinder, ...etc to be able to use ceph pools? > > Regards. From marios at redhat.com Tue Sep 7 05:59:23 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 7 Sep 2021 08:59:23 +0300 Subject: goodbye openstack, welcome ansible In-Reply-To: References: Message-ID: good luck on the new role! also i will ping you in a bit too discuss the 'requests' dependency in get-hash for dstream use case ;) :D regards On Monday, September 6, 2021, Sorin Sbarnea wrote: > Today was my last day as a part of the OpenStack team at Red Hat. After > almost 5 years, I've decided to use the opportunity to join the newly > created Ansible DevTools team, a team that will improve and maintain > development tools such as ansible-lint, molecule and the more recent > Ansible extension for VS Code. > > If you are interested in finding out more, make sure to attend the next Ansible > Contributor Summit > which is > happening at the end of this month. > > To those who will be missing me, don't worry I will not be far away. > > Cheers! > Sorin Sbarnea > -- _sent from my mobile - sorry for spacing spelling etc_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrei.perepiolkin at open-e.com Tue Sep 7 07:03:25 2021 From: andrei.perepiolkin at open-e.com (Andrei Perapiolkin) Date: Tue, 7 Sep 2021 03:03:25 -0400 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: Hi Team, I'd like to request FFE to the following change: [1] JovianDSS: add multiattach and 16K block support https://review.opendev.org/c/openstack/cinder/+/806726 - Patch adds multiattach support and 16K block size support for Open-E JovianDSS driver. [2] JovianDSS: fix code style and naming https://review.opendev.org/c/openstack/cinder/+/806559 - Patch adds minor code style and naming changes Both changes were parts of a single patch: [3] https://review.opendev.org/c/openstack/cinder/+/806559 That was split in parts according to recommendations. Patches are merged by now. They are isolated to the Open-E JovianDSS driver module, and have no impact on the Cinder database, REST/RPC and APIs. Best regards, Andrei On 9/3/21 4:55 PM, Brian Rosmaita wrote: > The Xena feature freeze for cinder is now in effect.  Please do not > approve patches proposing features for master until after the > stable/xena branch has been cut the week of 13 September. > > The following blueprints are granted feature freeze exceptions: > - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x > - https://blueprints.launchpad.net/cinder/+spec/remove-sqlalchemy-migrate > > Any other feature patches (including driver features) that have not > yet merged and are associated with an approved xena blueprint may > apply for a Feature Freeze Exception by replying to this email before > Tuesday, 7 September at 20:00 UTC.  Note that application for an FFE > is not a guarantee that an FFE will be granted.  Grant of an FFE is > not a guarantee that the code will be merged for Xena. > > It is expected that patches granted an FFE will be merged by 21:00 UTC > on Monday 13 September. > > Bugfixes do not require an FFE.  To be included in Xena, they must be > merged before the first Release Candidate is cut on Thursday 16 > September.  After that point, only release-critical bugfixes will be > allowed into the Xena release. > > Ping me in IRC if you have any questions. > > cheers, > brian > From v at prokofev.me Tue Sep 7 07:40:34 2021 From: v at prokofev.me (Vladimir Prokofev) Date: Tue, 7 Sep 2021 10:40:34 +0300 Subject: [tempest] change output format Message-ID: Hello. Is there a way to change the output format of tempest tests? Preferably to JSON. So instead of test something... ok it produced the same result but in JSON format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Tue Sep 7 08:59:43 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Tue, 7 Sep 2021 09:59:43 +0100 Subject: Backup TripleO instances Message-ID: Hi, I found out that Freezer is not supported by TripleO. - Can Freezer be integrated with TripleO? - Is there any other free software that can be used to backup instances that can easily be integrated with TripleO. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gchamoul at redhat.com Tue Sep 7 09:06:08 2021 From: gchamoul at redhat.com (=?utf-8?B?R2HDq2w=?= Chamoulaud) Date: Tue, 7 Sep 2021 11:06:08 +0200 Subject: goodbye openstack, welcome ansible In-Reply-To: References: Message-ID: <20210907090608.uvpk5m3lmyrpxxgv@gchamoul-mac> Very good luck on your new position, Sorin! You will definitely be missed. On 06/Sep/2021 09:32, Sorin Sbarnea wrote: > Today was my last day as a part of the OpenStack team at Red Hat. After almost > 5 years, I've decided to use the opportunity to join the newly created Ansible > DevTools team, a team that will improve and maintain development tools such as > ansible-lint, molecule and the more recent Ansible extension for VS Code. > > If you are interested in finding out more, make sure to attend the next Ansible > Contributor Summit which is happening at the end of this month. > > To those who will be missing me, don't worry I will not be far away. > > Cheers! > Sorin Sbarnea Best Regards, Gaël -- Gaël Chamoulaud - (He/Him/His) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From zigo at debian.org Tue Sep 7 09:09:45 2021 From: zigo at debian.org (Thomas Goirand) Date: Tue, 7 Sep 2021 11:09:45 +0200 Subject: [all] Dangerous trend toward too many release-independent components Message-ID: Hi, As I'm packaging Xena in Debian, I've seen more and more components switching to release-independent. This poses a number of problems which I'm really unsure how to address. Let me explain. First of all, once an OpenStack release reaches a distribution stable release, there will be no update of it (ie: no new upstream release), unless there's a security problems, or important bugfixes that cannot be backported individually. At least, that's how Debian works, and why we call our suite "stable" (ie: it doesn't change). However, if a component is declared release-independent, the OpenStack community expects it to be updated for all downward releases. But that's not what's going on in reality. Also, if there's a security fix, we're supposed to get this through an update of a new version, which may include changes not suitable for a distribution update. The danger is that the update may be refused by the Debian Stable release team, for very good reasons (which I agree on). I'm also questioning myself: since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now? So, while I do understand why it's nicer to set release-independent tags on some components, it is my opinion that this doesn't help stability and poses numerous problems to downstream distributions. Could we limit the number of such release-independent released components to the strict minimum low-profile (ie: with the least amount of code) components, rather than constantly increasing the list? Your thoughts? Cheers, Thomas Goirand (zigo) From moreira.belmiro.email.lists at gmail.com Tue Sep 7 09:10:07 2021 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Tue, 7 Sep 2021 11:10:07 +0200 Subject: [all][elections][ptl] PTL Voting Last Day - Cyborg Message-ID: Hello Cyborg contributors, Just a quick reminder that elections are closing soon, if you haven't already you should use your right to vote and pick your favourite candidate! You have until Sep 07, 2021 23:45 UTC. Belmiro, On behalf of all the Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Sep 7 09:19:17 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 07 Sep 2021 11:19:17 +0200 Subject: [nova][placement] nova-next job is broken In-Reply-To: <1M80ZQ.S70WTG0D8TSL1@est.tech> References: <1M80ZQ.S70WTG0D8TSL1@est.tech> Message-ID: <5K42ZQ.IAJ6MORGWXO32@est.tech> Hi, Yesterday we released a new osc-placement lib[1] and it seems it is resolved the problem with the nova-next job[2]. You can try to recheck failed builds. Cheers, gibi [1] https://review.opendev.org/c/openstack/requirements/+/807605 [2] https://zuul.opendev.org/t/openstack/builds?job_name=nova-next&branch=master On Mon, Sep 6, 2021 at 10:51, Balazs Gibizer wrote: > Hi, > > Since Friday the nova-next job fails with POST_FAILURE[1] due to the > new osc-placement release. Please hold you rechecks. > > [1] https://bugs.launchpad.net/nova/+bug/1942740 > > Cheers, > gibi > > > > From chkumar at redhat.com Tue Sep 7 09:20:36 2021 From: chkumar at redhat.com (Chandan Kumar) Date: Tue, 7 Sep 2021 14:50:36 +0530 Subject: goodbye openstack, welcome ansible In-Reply-To: References: Message-ID: On Mon, Sep 6, 2021 at 10:08 PM Sorin Sbarnea wrote: > > Today was my last day as a part of the OpenStack team at Red Hat. After almost 5 years, I've decided to use the opportunity to join the newly created Ansible DevTools team, a team that will improve and maintain development tools such as ansible-lint, molecule and the more recent Ansible extension for VS Code. > > If you are interested in finding out more, make sure to attend the next Ansible Contributor Summit which is happening at the end of this month. > > To those who will be missing me, don't worry I will not be far away. Thank you for all the contributions to OpenStack. We will miss you. All the best for a new adventure. :-) Thanks, Chandan Kumar From thierry at openstack.org Tue Sep 7 09:27:29 2021 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 7 Sep 2021 11:27:29 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: References: Message-ID: <87682f00-8d19-36c2-5911-622fc3d0c988@openstack.org> Thomas Goirand wrote: > As I'm packaging Xena in Debian, I've seen more and more components > switching to release-independent. This poses a number of problems which > I'm really unsure how to address. Let me explain. > > First of all, once an OpenStack release reaches a distribution stable > release, there will be no update of it (ie: no new upstream release), > unless there's a security problems, or important bugfixes that cannot be > backported individually. At least, that's how Debian works, and why we > call our suite "stable" (ie: it doesn't change). > > However, if a component is declared release-independent, the OpenStack > community expects it to be updated for all downward releases. But that's > not what's going on in reality. Also, if there's a security fix, we're > supposed to get this through an update of a new version, which may > include changes not suitable for a distribution update. The danger is > that the update may be refused by the Debian Stable release team, for > very good reasons (which I agree on). > > I'm also questioning myself: since we have pinned global requirements, > will these new updates be included in the tests of older OpenStack > releases? Is this really the case right now? > > So, while I do understand why it's nicer to set release-independent tags > on some components, it is my opinion that this doesn't help stability > and poses numerous problems to downstream distributions. > > Could we limit the number of such release-independent released > components to the strict minimum low-profile (ie: with the least amount > of code) components, rather than constantly increasing the list? Hi Thomas, Those are all good points, and we will discuss them at the release team level. For context, recently the release team has encouraged a number of stale components (stable libraries etc.) to move to release-independent since they were not even seeing one release per cycle. There was no point in forcing releases every cycle that were just changing the branch name in .gitreview. Regards, -- Thierry Carrez (ttx) From jpodivin at redhat.com Tue Sep 7 11:06:47 2021 From: jpodivin at redhat.com (Jiri Podivin) Date: Tue, 7 Sep 2021 13:06:47 +0200 Subject: goodbye openstack, welcome ansible In-Reply-To: References: Message-ID: Good luck in the Ansible DevTools team Sorin! Regards, On Tue, Sep 7, 2021 at 11:23 AM Chandan Kumar wrote: > On Mon, Sep 6, 2021 at 10:08 PM Sorin Sbarnea wrote: > > > > Today was my last day as a part of the OpenStack team at Red Hat. After > almost 5 years, I've decided to use the opportunity to join the newly > created Ansible DevTools team, a team that will improve and maintain > development tools such as ansible-lint, molecule and the more recent > Ansible extension for VS Code. > > > > If you are interested in finding out more, make sure to attend the next > Ansible Contributor Summit which is happening at the end of this month. > > > > To those who will be missing me, don't worry I will not be far away. > > Thank you for all the contributions to OpenStack. > We will miss you. > All the best for a new adventure. :-) > > Thanks, > > Chandan Kumar > > > -- Jiri Podivin Associate Software Engineer, Openstack Red Hat Czech, s.r.o. Purkyňova 3080/97b 61200 Brno, Czech Republic jpodivin at redhat.com M: +420739108412 IRC: jpodivin -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Sep 7 11:07:55 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 07 Sep 2021 12:07:55 +0100 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> Message-ID: <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> resending to correct list On Tue, 2021-09-07 at 10:51 +0100, Sean Mooney wrote: > hi i was jsut looking at the yoga runtimes an notice that we have not really updated it > with regards to minium python versions. > > currently > > the runtime defintion is as follows https://github.com/openstack/governance/blob/master/reference/runtimes/yoga.rst > > It is the :doc:`policy <../../resolutions/20181024-python-update-process>` that each OpenStack release cycle will target the latest available version of Python; default Python runtimes on the > distributions listed above; and versions used in integration tests at the start of the cycle, at least until the point when all projects have migrated to a later version. > > Based on the criteria above, all Python-based projects must target and test against, at a minimum: > > Python 3.6 (default in CentOS 8 Stream) > Python 3.8 (latest available; default in Ubuntu 20.04) > > looking at to look at https://repology.org/project/python/versions what python version are shpping by default now in many distro > more and more of them are moving to python 3.9 which is currently not in the test list and wer are starting to fall quite far behind > > debian 11/12/stable are currently using 3.9.2 > centos 8 defaults to 3.6.8 but ships 3.8.6 and 3.9.2 as appstreams > centos 9 stream will default to python3-3.9.6-6.el9.x86_64.rpm https://composes.stream.centos.org/test/latest-CentOS-Stream/compose/BaseOS/x86_64/os/Packages/ > ubuntu 20.04 default to 3.8.2 but also ships 3.9.5 in universe > ubuntu 21.04 default to 3.9.5 so we can expect that when yoga ships on ubuntu 22.04 it will be based on at least python 3.9 and proably 3.10 > fedora well they basically ship everythin but i belive 3.9 is not the default based on complaints some of my fellow contiutors had with > runnign unit and functional tests. > > openSUSE Leap 15.3 main/oss python39 3.9.4 ship 3.9 but default to 3.6 > they aslo nolonger have an openstack product but it would still be nice to keep them in mind. > > > over all i think we shoudl consider raising or min tested/supported python version to python 3.8 for yoga and consider updating from centos 8 to centos 9. > i also think it worth including python 3.9 in the required testing versions for python projects. > > several distros will be releaseing openstack xena/wallaby with python 3.9 and also yoga likely with 3.10 in some cases. > if we only offically test with 3.6 and 3.8 we could have some hard probalems to solve going forward. the optional testing with unit and functional tests > that some project have for python 3.9 certenly helps but actully having an integrated tempest gate job that runs on 3.9 i think is going to be increasingly important. > > readring centos 9 stream, it was orginally planned of release at the end of q2. now that date has obviosly passed but i know that they are still hopeful to have > a release ready in the next month or so. cloud images are avaibel at https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ although the repos are still only > partly complete https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ and there are currently no active mirros so its still officaly > not released https://www.centos.org/centos-stream/ and i don not have any ETA beyond soonTM. as such im aware we cant offically declare centos 9 stream as part of the tested > runtimes at this point but it might be at least worht listing it as an experimtal runtime as i suspec there will be a desire to swtich to it during the yoga cycle for some proejct. > ooo/rdo come to mind as they discussed this for xena but obviously that was not possibel since it was not released in time. > > > regards > sean. > > ps removing python 3.6 and replacing it with 3.9 instead of just adding 3.9 as an addtional runtime is more to manage our testing > there isnt nessarly any python feature that i explcitly would like to be able to use that are added in 3.8 that would be enabled > by making that the new min python verion that is motivating this suggestion. there are some nice thingin 3.9/3.10 such as pattern > mataching that are commign but it will be some time (2-4 years)before we can actully use those as our min version so i was just being practial > and suggestion we raise to 3.8 and add 3.9 as required with 3.10 as optional/experimal for those that want it. > From rosmaita.fossdev at gmail.com Tue Sep 7 11:37:50 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 7 Sep 2021 07:37:50 -0400 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: <07fd4237-481c-4300-d7aa-0d2dfc95bd2a@gmail.com> These patches have both had +2s at some point in the reviewing process, and it looks like the only changes have been merge conflict resolution, so these are granted FFEs subject to the caveats in original email. On 9/3/21 5:09 PM, Fernando Ferraz wrote: > Hi Team, > > I'd like to request FFE to the following changes: > > [1] Netapp ONTAP: Add support to revert to snapshot > https://review.opendev.org/c/openstack/cinder/+/804093 > > - Patch adds support for the revert to snapshot feature to the NetApp Cinder > drivers. > > [2] NetApp ONTAP: Add option to report storage provisioned capacity > https://review.opendev.org/c/openstack/cinder/+/798198 > > - Patch adds an option to enable a new pool capability > provisioned_capacity_gb > that reports storage provisioned volume sizes directly from the storage > system, > instead of relying on the default scheduler's behavior based on internal > states. > > Both changes and their blueprints were submitted in time and there has been > significant progress in the reviews until this point. They are isolated to > the NetApp driver module, and have no impact on the Cinder database, > REST/RPC and APIs. > > Regards, > Fernando > > > Em sex., 3 de set. de 2021 às 18:01, Brian Rosmaita > > escreveu: > > The Xena feature freeze for cinder is now in effect.  Please do not > approve patches proposing features for master until after the > stable/xena branch has been cut the week of 13 September. > > The following blueprints are granted feature freeze exceptions: > - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x > > - > https://blueprints.launchpad.net/cinder/+spec/remove-sqlalchemy-migrate > > > Any other feature patches (including driver features) that have not yet > merged and are associated with an approved xena blueprint may apply for > a Feature Freeze Exception by replying to this email before Tuesday, 7 > September at 20:00 UTC.  Note that application for an FFE is not a > guarantee that an FFE will be granted.  Grant of an FFE is not a > guarantee that the code will be merged for Xena. > > It is expected that patches granted an FFE will be merged by 21:00 UTC > on Monday 13 September. > > Bugfixes do not require an FFE.  To be included in Xena, they must be > merged before the first Release Candidate is cut on Thursday 16 > September.  After that point, only release-critical bugfixes will be > allowed into the Xena release. > > Ping me in IRC if you have any questions. > > cheers, > brian > From rosmaita.fossdev at gmail.com Tue Sep 7 12:17:31 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 7 Sep 2021 08:17:31 -0400 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: <69ed5cf1-5858-96a1-871c-07ba47b36e94@gmail.com> This is a fairly large patch, but it is confined to a single driver and is unlikely to impact the main cinder code. I feel a lot better about its code coverage since you figured out the unit test discovery problem. So this patch is granted an FFE subject to the caveats in the original email. On 9/6/21 2:48 PM, 野村和正 / NOMURA，KAZUMASA wrote: > Hi Team, > > I'd like to request FFE to the following change: > > [1] Hitachi: Add generic volume groups > https://review.opendev.org/c/openstack/cinder/+/782910 > - This patch adds consistency group capability as generic volume groups > for the Hitachi driver. > > This change and blueprint were submitted in time and it has been > good progress in the reviews until this point. This patch is isolated to > the Hitachi driver module, and have no impact on the Cinder database, > REST/RPC and APIs. > > Kind Regards, > Kazumasa Nomura > > -----Original Message----- > From: Brian Rosmaita > Sent: Saturday, September 4, 2021 5:55 AM > To: openstack-discuss at lists.openstack.org > Subject: [!][cinder] xena feature freeze > > The Xena feature freeze for cinder is now in effect. Please do not approve patches proposing features for master until after the stable/xena branch has been cut the week of 13 September. > > The following blueprints are granted feature freeze exceptions: > - https://secure-web.cisco.com/1esUHJyUlDOFXd10REcKVNw8NBLq3WM7zB53bQ2dG6d_4AKYrcnDvITVjZOXPlqoguipoly92XJj_W3xyJJXJkN9lP27RobrMUbliwyUrQYv2w7pRlBj-ikdJiRK5Tgh4tKsxdNufvDl39xyiVWpPnc4cD4GnXKMObQBa5UHG__8gMhk4v3biFveL4uaBjziC5fw9mzI1hOZyvFBhR36p5TVR4FnPdZ9DQ0jOoJ_YGcfdTZNzaadIlYA9HaMPhIo0wYdpjxBEBI9DYd_4inMliFshH-dLz4OWtvsu9bH21lOoU994XxUpyizz45wdPY_W/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fs-rbac-ready-x > - https://secure-web.cisco.com/1wxRMdxHHb-gemG2KizQtfPjVmtpBfsSPKKdJXHmCPFs6L9o7JMH8uHQahyjUFbqwMGZz_SG5lNgP-DwS5dojrm-h3OhiOJFW1sf2QDBsshmMAhfM5srV3EYjsrtR49oFwMWw-fpQiM9T0DNSebWXVa_RvoS0BFix9oEasQxVe445BuRf23R3Z5WJ4EnyS0LB-kS00pI4Wng4mIg9216x_2hL1Te3d2GvmYCOdoYKVKxuDi019xG8lR5OTZGRqfRzj7yBXwWYSJihXxn1YRIUegKHGfi5mhG9_Jy-p-qVJrd8PWrrWrr3oLuT8Gy6-5u5/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2F%2Bspec%2Fremove-sqlalchemy-migrate > > Any other feature patches (including driver features) that have not yet merged and are associated with an approved xena blueprint may apply for a Feature Freeze Exception by replying to this email before Tuesday, 7 September at 20:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Xena. > > It is expected that patches granted an FFE will be merged by 21:00 UTC on Monday 13 September. > > Bugfixes do not require an FFE. To be included in Xena, they must be merged before the first Release Candidate is cut on Thursday 16 September. After that point, only release-critical bugfixes will be allowed into the Xena release. > > Ping me in IRC if you have any questions. > > cheers, > brian > > From rosmaita.fossdev at gmail.com Tue Sep 7 12:46:16 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 7 Sep 2021 08:46:16 -0400 Subject: [cinder] xena feature freeze In-Reply-To: References: Message-ID: <8a796afb-0a62-d964-20ee-51903e7e278e@gmail.com> Hi Andrei, [1] and [2] are granted FFEs; they've had +2s at various points and probably would have merged before the deadline except for some gate weirdness. I think you have a typo in [3], and are referring to: https://review.opendev.org/c/openstack/cinder/+/794962 Please go ahead and abandon [3] as it's no longer relevant. (As the reason, you can say "Superseded by https://review.opendev.org/c/openstack/cinder/+/806726 and https://review.opendev.org/c/openstack/cinder/+/806559".) On 9/7/21 3:03 AM, Andrei Perapiolkin wrote: > Hi Team, > > I'd like to request FFE to the following change: > > [1] JovianDSS: add multiattach and 16K block support > https://review.opendev.org/c/openstack/cinder/+/806726 > > - Patch adds multiattach support and 16K block size support > for Open-E JovianDSS driver. > > > [2] JovianDSS: fix code style and naming > https://review.opendev.org/c/openstack/cinder/+/806559 > > > - Patch adds minor code style and naming changes > > > Both changes were parts of a single patch: > [3] https://review.opendev.org/c/openstack/cinder/+/806559 > > That was split in parts according to recommendations. > Patches are merged by now. > They are isolated to the Open-E JovianDSS driver module, and have no > impact on the Cinder database, > REST/RPC and APIs. > > Best regards, > Andrei > > > On 9/3/21 4:55 PM, Brian Rosmaita wrote: >> The Xena feature freeze for cinder is now in effect.  Please do not >> approve patches proposing features for master until after the >> stable/xena branch has been cut the week of 13 September. >> >> The following blueprints are granted feature freeze exceptions: >> - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x >> - https://blueprints.launchpad.net/cinder/+spec/remove-sqlalchemy-migrate >> >> Any other feature patches (including driver features) that have not >> yet merged and are associated with an approved xena blueprint may >> apply for a Feature Freeze Exception by replying to this email before >> Tuesday, 7 September at 20:00 UTC.  Note that application for an FFE >> is not a guarantee that an FFE will be granted.  Grant of an FFE is >> not a guarantee that the code will be merged for Xena. >> >> It is expected that patches granted an FFE will be merged by 21:00 UTC >> on Monday 13 September. >> >> Bugfixes do not require an FFE.  To be included in Xena, they must be >> merged before the first Release Candidate is cut on Thursday 16 >> September.  After that point, only release-critical bugfixes will be >> allowed into the Xena release. >> >> Ping me in IRC if you have any questions. >> >> cheers, >> brian >> > From dtantsur at redhat.com Tue Sep 7 13:08:58 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 7 Sep 2021 15:08:58 +0200 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> Message-ID: On Tue, Sep 7, 2021 at 1:10 PM Sean Mooney wrote: > resending to correct list > On Tue, 2021-09-07 at 10:51 +0100, Sean Mooney wrote: > > hi i was jsut looking at the yoga runtimes an notice that we have not > really updated it > > with regards to minium python versions. > > > > currently > > > > the runtime defintion is as follows > https://github.com/openstack/governance/blob/master/reference/runtimes/yoga.rst > > > > It is the :doc:`policy > <../../resolutions/20181024-python-update-process>` that each OpenStack > release cycle will target the latest available version of Python; default > Python runtimes on the > > distributions listed above; and versions used in integration tests at > the start of the cycle, at least until the point when all projects have > migrated to a later version. > > > > Based on the criteria above, all Python-based projects must target > and test against, at a minimum: > > > > Python 3.6 (default in CentOS 8 Stream) > > Python 3.8 (latest available; default in Ubuntu 20.04) > > > > looking at to look at https://repology.org/project/python/versions what > python version are shpping by default now in many distro > > more and more of them are moving to python 3.9 which is currently not in > the test list and wer are starting to fall quite far behind > > > > debian 11/12/stable are currently using 3.9.2 > > centos 8 defaults to 3.6.8 but ships 3.8.6 and 3.9.2 as appstreams > We shouldn't rely on non-default versions. > > centos 9 stream will default to python3-3.9.6-6.el9.x86_64.rpm > https://composes.stream.centos.org/test/latest-CentOS-Stream/compose/BaseOS/x86_64/os/Packages/ > > ubuntu 20.04 default to 3.8.2 but also ships 3.9.5 in universe > Same. > > ubuntu 21.04 default to 3.9.5 so we can expect that when yoga ships on > ubuntu 22.04 it will be based on at least python 3.9 and proably 3.10 > > fedora well they basically ship everythin but i belive 3.9 is not the > default based on complaints some of my fellow contiutors had with > > runnign unit and functional tests. > > > > openSUSE Leap 15.3 main/oss python39 3.9.4 ship 3.9 but default > to 3.6 > > they aslo nolonger have an openstack product but it would still be nice > to keep them in mind. > Yep, some of us (namely Bifrost) support openSUSE Leap (and the transition to 15.3 hasn't happened yet) > > > > > > over all i think we shoudl consider raising or min tested/supported > python version to python 3.8 for yoga and consider updating from centos 8 > to centos 9. > Dropping CentOS 8 (and thus RHEL 8) support before RHEL 9 is released seems extremely premature to me. I understand that with CentOS Stream the world got some access to in-progress RHEL versions, but it does not change the fact that RHEL 9 does not exist yet, and there seems to be no public information on when it will appear. >From your analysis it seems that we should support 3.6 (CentOS/RHEL), 3.8 (Ubuntu 20.04) and 3.9 (Fedora, openSUSE, future RHEL). Dmitry > > i also think it worth including python 3.9 in the required testing > versions for python projects. > > > > several distros will be releaseing openstack xena/wallaby with python > 3.9 and also yoga likely with 3.10 in some cases. > > if we only offically test with 3.6 and 3.8 we could have some hard > probalems to solve going forward. the optional testing with unit and > functional tests > > that some project have for python 3.9 certenly helps but actully having > an integrated tempest gate job that runs on 3.9 i think is going to be > increasingly important. > > > > readring centos 9 stream, it was orginally planned of release at the end > of q2. now that date has obviosly passed but i know that they are still > hopeful to have > > a release ready in the next month or so. cloud images are avaibel at > https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ > although the repos are still only > > partly complete > https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ > and there are currently no active mirros so its still officaly > > not released https://www.centos.org/centos-stream/ and i don not have > any ETA beyond soonTM. as such im aware we cant offically declare centos 9 > stream as part of the tested > > runtimes at this point but it might be at least worht listing it as an > experimtal runtime as i suspec there will be a desire to swtich to it > during the yoga cycle for some proejct. > > ooo/rdo come to mind as they discussed this for xena but obviously that > was not possibel since it was not released in time. > > > > > > regards > > sean. > > > > ps removing python 3.6 and replacing it with 3.9 instead of just adding > 3.9 as an addtional runtime is more to manage our testing > > there isnt nessarly any python feature that i explcitly would like to be > able to use that are added in 3.8 that would be enabled > > by making that the new min python verion that is motivating this > suggestion. there are some nice thingin 3.9/3.10 such as pattern > > mataching that are commign but it will be some time (2-4 years)before we > can actully use those as our min version so i was just being practial > > and suggestion we raise to 3.8 and add 3.9 as required with 3.10 as > optional/experimal for those that want it. > > > > > > -- 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 fungi at yuggoth.org Tue Sep 7 13:29:53 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 7 Sep 2021 13:29:53 +0000 Subject: [tempest] change output format In-Reply-To: References: Message-ID: <20210907132953.wyjqzge5u6d2hk5n@yuggoth.org> On 2021-09-07 10:40:34 +0300 (+0300), Vladimir Prokofev wrote: > Is there a way to change the output format of tempest tests? > Preferably to JSON. So instead of test something... ok it produced > the same result but in JSON format. Tempest produces a subunit stream with details of all the tests performed. This is a standard data exchange format for test results, which can be readily parsed with a library like https://pypi.org/project/python-subunit/ after which serializing to JSON would presumably be a trivial exercise (or just consume the subunit stream directly if the desire was merely to use JSON for programmatic parsing, that's what the subunit is for anyway). -- 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 fungi at yuggoth.org Tue Sep 7 13:39:47 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 7 Sep 2021 13:39:47 +0000 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: References: Message-ID: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote: [...] > since we have pinned global requirements, will these new updates > be included in the tests of older OpenStack releases? Is this > really the case right now? [...] They generally shouldn't, and most of the time can't realistically, have their entries altered in stable branches of the upper-constraints.txt file we use to pin dependency versions. To be able to do so would prevent them from using new features of their own dependencies in master branch development, since those would end up also needing updates in the pinned list of transitive stable branch constraints, which is exactly what we want to avoid. The workaround is to create a stable branch of the repository from the last version which was tagged during the cycle for the release which needs a fix to that independent deliverable backported. Those cases are rare, and basically what you would include as a stable distro package update for that coordinated release series anyway. -- 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 haleyb.dev at gmail.com Tue Sep 7 13:44:35 2021 From: haleyb.dev at gmail.com (Brian Haley) Date: Tue, 7 Sep 2021 09:44:35 -0400 Subject: [neutron] Bug deputy report for week of August 30th Message-ID: <2322b0cb-a26a-8559-618f-8bd588343bd4@gmail.com> Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1942190 - [Fullstack] Timeout while waiting for port to be active - https://review.opendev.org/c/openstack/neutron/+/807134 Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1942033 - Mechanism driver 'ovn' failed in update_port_postcommit: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound - q-dhcp was also enabled in config causing the issue, removing fixed it * https://bugs.launchpad.net/neutron/+bug/1942251 - Routes has not added after router restart - https://review.opendev.org/c/openstack/neutron/+/721799 * https://bugs.launchpad.net/neutron/+bug/1942344 - ovs2ovn migration tool fails using VALIDATE_MIGRATION=False - https://review.opendev.org/c/openstack/neutron/+/806942 * https://bugs.launchpad.net/neutron/+bug/1942413 - subport status is not updated when trunk or subport notification is received - https://review.opendev.org/c/openstack/neutron/+/807076 * https://bugs.launchpad.net/neutron/+bug/1942615 - SG shared through RBAC mechanism can't be used to spawn instances - Slawek took ownership * https://bugs.launchpad.net/neutron/+bug/1942617 - SG rules from SG shared using RBAC aren't visible - Slawek took ownership Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1942234 - [OVS] Device "update" information could look the same between two different updates - https://review.opendev.org/c/openstack/neutron/+/806889 * https://bugs.launchpad.net/neutron/+bug/1942237 - Changed FIP event in Ie4c0f4a63a87c32026c49b03068e5f461deb38b6 - Won't fix - consumers have been fixed * https://bugs.launchpad.net/neutron/+bug/1942358 - Use "objects_exist" in port forwarding plugin - https://review.opendev.org/c/openstack/neutron/+/806962 * https://bugs.launchpad.net/neutron/+bug/1942448 - Neutron - “Update bandwidth limit rule” API on SUCCESS responds with 200 instead of Expected 202 - Looks like an api-ref typo - https://review.opendev.org/c/openstack/neutron-lib/+/807390 * https://bugs.launchpad.net/neutron/+bug/1942469 - Network delete notifications no longer contain segment info - Broken with https://review.opendev.org/c/openstack/neutron/+/786373 - https://review.opendev.org/c/openstack/neutron/+/807243 Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/1942458 - NeutronNetworks.create_and_delete_subnets fails NotFound - Asked for more information, could be container-related - Moved to neutron-charm for more investigation Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1942294 - Is allow_overlapping_ips config option still needed really? From dms at danplanet.com Tue Sep 7 14:07:14 2021 From: dms at danplanet.com (Dan Smith) Date: Tue, 07 Sep 2021 07:07:14 -0700 Subject: Adding another cell(v2) In-Reply-To: (Alexander Dibbo's message of "Mon, 6 Sep 2021 10:57:43 +0000") References: Message-ID: > Could someone point me to the documentation on how to add a new cell to cellsv2? I have found various documentation that says > to follow the procedure for Cells V1 but I cant find documentation for that. Below is the link to the doc I have found > > https://docs.openstack.org/nova/train/user/cells.html Yeah, this bullet in the doc you provided is what we have: https://docs.openstack.org/nova/latest/user/cells.html#adding-a-new-cell-to-an-existing-deployment It directs you to a different part of the page to run a single step of the v1 upgrade procedure. We obviously need to remove the v1 stuff and make the "add a new cell" thing stand on its own. There's a note in the latest version about that. But for the moment, you just need to create a new cell record with nova-manage (as described in that doc), pointing at the DB and MQ for the new cell. Then 'db sync' should hit that cell and blow in the schema just like it does for your main cell. Once that is done, start up conductors and computes pointing at the new cell MQ and DB and run the host discovery and make sure it finds the services registered in the new cell. --Dan From dmendiza at redhat.com Tue Sep 7 14:13:37 2021 From: dmendiza at redhat.com (Douglas Mendizabal) Date: Tue, 7 Sep 2021 09:13:37 -0500 Subject: [keystone] Weekly meetings In-Reply-To: References: Message-ID: On 8/18/21 10:39 AM, Douglas Mendizabal wrote: > 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 Hi All, Just a reminder that we'll be meeting at 1500 UTC today. Thanks, - Douglas Mendizábal (redrobot) From fungi at yuggoth.org Tue Sep 7 14:55:25 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 7 Sep 2021 14:55:25 +0000 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> Message-ID: <20210907145525.jhc4wfgsziyyabh5@yuggoth.org> On Tue, 2021-09-07 at 10:51 +0100, Sean Mooney wrote: > hi i was jsut looking at the yoga runtimes an notice that we have > not really updated it with regards to minium python versions. [...] That was introduced in July via https://review.opendev.org/799927 but should probably be considered a placeholder for now. We determine what versions of Python to target at or just prior to the start of the development cycle in order to use the latest information available to us, while avoiding changing team focus during the cycle. There's certainly still time to update it to include Python 3.9, and we do in fact already run (mostly non-voting) unit tests of many projects with 3.9. You may as well go ahead and push your proposed edit for review, it may not need much discussion. -- 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 tonykarera at gmail.com Tue Sep 7 15:00:59 2021 From: tonykarera at gmail.com (Karera Tony) Date: Tue, 7 Sep 2021 17:00:59 +0200 Subject: Octavia Issue: Failed to build compute instance due to: Failed to retrieve image with amphora tag Message-ID: Hello Team, I have openstack wallaby running on Ubuntu deployed using kolla-ansible but whenever I create a load balancer I get the error below in the octavia-worker.log octavia.common.exceptions.ComputeBuildException: Failed to build compute instance due to: Failed to retrieve image with amphora tag 2021-09-06 14:14:49.392 20 ERROR oslo_messaging.rpc.server But I have an image with the correct tag as shown below. (kolla-openstack) stack at deployment:~$ openstack image show amphora1 | grep tag | tags | amphora Kindly advise if I am missing anything. Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Sep 7 15:38:12 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 07 Sep 2021 10:38:12 -0500 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> Message-ID: <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> ---- On Tue, 07 Sep 2021 06:07:55 -0500 Sean Mooney wrote ---- > resending to correct list > On Tue, 2021-09-07 at 10:51 +0100, Sean Mooney wrote: > > hi i was jsut looking at the yoga runtimes an notice that we have not really updated it > > with regards to minium python versions. > > > > currently > > > > the runtime defintion is as follows https://github.com/openstack/governance/blob/master/reference/runtimes/yoga.rst > > > > It is the :doc:`policy <../../resolutions/20181024-python-update-process>` that each OpenStack release cycle will target the latest available version of Python; default Python runtimes on the > > distributions listed above; and versions used in integration tests at the start of the cycle, at least until the point when all projects have migrated to a later version. > > > > Based on the criteria above, all Python-based projects must target and test against, at a minimum: > > > > Python 3.6 (default in CentOS 8 Stream) > > Python 3.8 (latest available; default in Ubuntu 20.04) > > > > looking at to look at https://repology.org/project/python/versions what python version are shpping by default now in many distro > > more and more of them are moving to python 3.9 which is currently not in the test list and wer are starting to fall quite far behind > > > > debian 11/12/stable are currently using 3.9.2 > > centos 8 defaults to 3.6.8 but ships 3.8.6 and 3.9.2 as appstreams > > centos 9 stream will default to python3-3.9.6-6.el9.x86_64.rpm https://composes.stream.centos.org/test/latest-CentOS-Stream/compose/BaseOS/x86_64/os/Packages/ > > ubuntu 20.04 default to 3.8.2 but also ships 3.9.5 in universe > > ubuntu 21.04 default to 3.9.5 so we can expect that when yoga ships on ubuntu 22.04 it will be based on at least python 3.9 and proably 3.10 > > fedora well they basically ship everythin but i belive 3.9 is not the default based on complaints some of my fellow contiutors had with > > runnign unit and functional tests. > > > > openSUSE Leap 15.3 main/oss python39 3.9.4 ship 3.9 but default to 3.6 > > they aslo nolonger have an openstack product but it would still be nice to keep them in mind. > > Definitely we can move to 3.9 as official testing runtime if any of the currently supporting distro support it as default. openSuse distro is not supported anymore due to no/less volunteer to maintain it. centos9 or Ubuntu 22.04 LTS is not yet released so we have not picked them yet but that is something we discussed during the review of defining Yoga testing runtime. If any of these distro is released before Yoga development cycle we can propose a update to the current testing runtime - https://review.opendev.org/c/openstack/governance/+/799927/1/reference/runtimes/yoga.rst#9 Also one thing to make a note here, py3.9 is being tested as non-voting in all the project unit tests and hopefully projects has made it green. There is no restriction to run unit or functional tests on py3.9 as voting testing. Testing runtime is just a minimum testing we except projects to do and it can be extended at any distro/versions at project level. -gmann > > > > over all i think we shoudl consider raising or min tested/supported python version to python 3.8 for yoga and consider updating from centos 8 to centos 9. > > i also think it worth including python 3.9 in the required testing versions for python projects. > > > > several distros will be releaseing openstack xena/wallaby with python 3.9 and also yoga likely with 3.10 in some cases. > > if we only offically test with 3.6 and 3.8 we could have some hard probalems to solve going forward. the optional testing with unit and functional tests > > that some project have for python 3.9 certenly helps but actully having an integrated tempest gate job that runs on 3.9 i think is going to be increasingly important. > > > > readring centos 9 stream, it was orginally planned of release at the end of q2. now that date has obviosly passed but i know that they are still hopeful to have > > a release ready in the next month or so. cloud images are avaibel at https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ although the repos are still only > > partly complete https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/images/ and there are currently no active mirros so its still officaly > > not released https://www.centos.org/centos-stream/ and i don not have any ETA beyond soonTM. as such im aware we cant offically declare centos 9 stream as part of the tested > > runtimes at this point but it might be at least worht listing it as an experimtal runtime as i suspec there will be a desire to swtich to it during the yoga cycle for some proejct. > > ooo/rdo come to mind as they discussed this for xena but obviously that was not possibel since it was not released in time. > > > > > > regards > > sean. > > > > ps removing python 3.6 and replacing it with 3.9 instead of just adding 3.9 as an addtional runtime is more to manage our testing > > there isnt nessarly any python feature that i explcitly would like to be able to use that are added in 3.8 that would be enabled > > by making that the new min python verion that is motivating this suggestion. there are some nice thingin 3.9/3.10 such as pattern > > mataching that are commign but it will be some time (2-4 years)before we can actully use those as our min version so i was just being practial > > and suggestion we raise to 3.8 and add 3.9 as required with 3.10 as optional/experimal for those that want it. > > > > > > From johnsomor at gmail.com Tue Sep 7 15:56:26 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Tue, 7 Sep 2021 08:56:26 -0700 Subject: Octavia Issue: Failed to build compute instance due to: Failed to retrieve image with amphora tag In-Reply-To: References: Message-ID: Hi Tony, As Greg mentioned in his reply to your previous email, that log line is truncated and doesn't tell us what issue you are seeing. Please see his response: http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024688.html Michael On Tue, Sep 7, 2021 at 8:07 AM Karera Tony wrote: > > Hello Team, > > I have openstack wallaby running on Ubuntu deployed using kolla-ansible > but whenever I create a load balancer I get the error below in the > octavia-worker.log > > octavia.common.exceptions.ComputeBuildException: Failed to build compute > instance due to: Failed to retrieve image with amphora tag > 2021-09-06 14:14:49.392 20 ERROR oslo_messaging.rpc.server > > But I have an image with the correct tag as shown below. > > (kolla-openstack) stack at deployment:~$ openstack image show amphora1 | > grep tag > | tags | amphora > > Kindly advise if I am missing anything. > Regards > > Tony Karera > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Sep 7 16:03:09 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 7 Sep 2021 16:03:09 +0000 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> Message-ID: <20210907160308.5qcih7675nbjwghu@yuggoth.org> On 2021-09-07 10:38:12 -0500 (-0500), Ghanshyam Mann wrote: [...] > Definitely we can move to 3.9 as official testing runtime if any > of the currently supporting distro support it as default. [...] I don't think it needs to be the default Python in a release so long as it's available. To quote from https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests "Prior to the beginning of each release cycle, the TC will designate the minor versions of Python 3 that will be tested in that release using the following criteria: [...] The latest released version of Python 3 that is available in any distribution we can feasibly use for testing. It need not be a long-term-supported release, but could be a non-LTS version of Ubuntu, Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian Testing or openSUSE Tumbleweed) if necessary." I recall clearly that this was added so that we would attempt to test the latest available version of Python in order to help avoid having software which is clearly non-functional on distributions which are working in parallel to update their defaults (and so might reasonably want to ship OpenStack with an interpreter version which was not their default at the time we started development for that coordinated release). -- 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 Tue Sep 7 16:44:02 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 07 Sep 2021 11:44:02 -0500 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <20210907160308.5qcih7675nbjwghu@yuggoth.org> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> <20210907160308.5qcih7675nbjwghu@yuggoth.org> Message-ID: <17bc125274c.114f9c117145230.1407351724601243402@ghanshyammann.com> ---- On Tue, 07 Sep 2021 11:03:09 -0500 Jeremy Stanley wrote ---- > On 2021-09-07 10:38:12 -0500 (-0500), Ghanshyam Mann wrote: > [...] > > Definitely we can move to 3.9 as official testing runtime if any > > of the currently supporting distro support it as default. > [...] > > I don't think it needs to be the default Python in a release so long > as it's available. To quote from > https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests > > "Prior to the beginning of each release cycle, the TC will > designate the minor versions of Python 3 that will be tested in > that release using the following criteria: > [...] > The latest released version of Python 3 that is available in any > distribution we can feasibly use for testing. It need not be a > long-term-supported release, but could be a non-LTS version of > Ubuntu, Fedora, openSUSE Leap, or even a rolling release > distribution (such as Debian Testing or openSUSE Tumbleweed) if > necessary." > > I recall clearly that this was added so that we would attempt to > test the latest available version of Python in order to help avoid > having software which is clearly non-functional on distributions > which are working in parallel to update their defaults (and so might > reasonably want to ship OpenStack with an interpreter version which > was not their default at the time we started development for that > coordinated release). Sure, and by seeing the current py39 job it is mostly passing - https://zuul.openstack.org/builds?job_name=openstack-tox-py39 Let's discuss it in PTG and hopefully by then we might see centos9 release or closure plan to release dates and as discussed during defining the Yoga tetsing runtime, we can update it once if centos9 is there then update centos versionb as well as the py version otherwise we can disucss only making py39 jobs voting which are running on ubuntu focal. -gmann > -- > Jeremy Stanley > From smooney at redhat.com Tue Sep 7 17:39:40 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 07 Sep 2021 18:39:40 +0100 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <17bc125274c.114f9c117145230.1407351724601243402@ghanshyammann.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> <20210907160308.5qcih7675nbjwghu@yuggoth.org> <17bc125274c.114f9c117145230.1407351724601243402@ghanshyammann.com> Message-ID: <50423dee4b245d18befa21bd7ef1666653f7bf2e.camel@redhat.com> On Tue, 2021-09-07 at 11:44 -0500, Ghanshyam Mann wrote: > ---- On Tue, 07 Sep 2021 11:03:09 -0500 Jeremy Stanley wrote ---- > > On 2021-09-07 10:38:12 -0500 (-0500), Ghanshyam Mann wrote: > > [...] > > > Definitely we can move to 3.9 as official testing runtime if any > > > of the currently supporting distro support it as default. > > [...] > > > > I don't think it needs to be the default Python in a release so long > > as it's available. To quote from > > https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests > > > > "Prior to the beginning of each release cycle, the TC will > > designate the minor versions of Python 3 that will be tested in > > that release using the following criteria: > > [...] > > The latest released version of Python 3 that is available in any > > distribution we can feasibly use for testing. It need not be a > > long-term-supported release, but could be a non-LTS version of > > Ubuntu, Fedora, openSUSE Leap, or even a rolling release > > distribution (such as Debian Testing or openSUSE Tumbleweed) if > > necessary." > > > > I recall clearly that this was added so that we would attempt to > > test the latest available version of Python in order to help avoid > > having software which is clearly non-functional on distributions > > which are working in parallel to update their defaults (and so might > > reasonably want to ship OpenStack with an interpreter version which > > was not their default at the time we started development for that > > coordinated release). > > Sure, and by seeing the current py39 job it is mostly passing > - https://zuul.openstack.org/builds?job_name=openstack-tox-py39 > > Let's discuss it in PTG and hopefully by then we might see centos9 > release or closure plan to release dates and as discussed during > defining the Yoga tetsing runtime, we can update it once if > centos9 is there then update centos versionb as well as the py version > otherwise we can disucss only making py39 jobs voting which are running > on ubuntu focal. not sure if centos 9 will be avaiable by ptg but i hope so. in anycaes ubuntu 21.04 default to python 3.9 and debian 11 "bullseye" which is the latest __stable__ debian release also default to python 3.9 as does fedora 34 but that a much bigger moving target. in general 3.9 is avaiable if not default in several distro which is why i would like to include it for required testing e.g. move the current non voting jobs to voting for unit and functest at least. it woudl be nice if we could have at least on tempst job on py39 too but sure lets pick this up at the ptg. im not agaisnt keeping support for phython 3.6 and centos 8 stream for yoga but i would like to be abel to do at least some smoke tests with centos 9 stream if its avaiable. the none stream version fo centos 8 i think is end of life at the end of this year? but the centos 8 stream release will continue untile rhel 8 is eol so that shoudl still be supproted to some degree for the full yoga cycle. the none stream version however wont be supported when yoga releases. > > -gmann > > > -- > > Jeremy Stanley > > > From mkopec at redhat.com Tue Sep 7 19:15:04 2021 From: mkopec at redhat.com (Martin Kopec) Date: Tue, 7 Sep 2021 21:15:04 +0200 Subject: [patrole][qa] Proposing Soniya Vyas to Patrole core Message-ID: Hi all, Soniya Vyas (IRC: soniya29) is very enthusiastic about Patrole project and since she has been very helpful, I'd like to propose her for Patrole core. You can vote/feedback on this email. If no objections within a week, I'll add her to the core list. Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Sep 7 19:29:49 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 07 Sep 2021 14:29:49 -0500 Subject: [patrole][qa] Proposing Soniya Vyas to Patrole core In-Reply-To: References: Message-ID: <17bc1bcebec.d7cc6895149770.7494147722877953142@ghanshyammann.com> ---- On Tue, 07 Sep 2021 14:15:04 -0500 Martin Kopec wrote ---- > Hi all, > > Soniya Vyas (IRC: soniya29) is very enthusiastic about Patrole project and since she has been very helpful, I'd like to propose her for Patrole core. > > You can vote/feedback on this email. If no objections within a week, I'll add her to the core list. +1, she has been very helpful in Patrole project. -gmann > > Regards, > -- > Martin Kopec > Senior Software Quality Engineer > Red Hat EMEA > > > From dmeng at uvic.ca Tue Sep 7 19:20:39 2021 From: dmeng at uvic.ca (dmeng) Date: Tue, 07 Sep 2021 12:20:39 -0700 Subject: [sdk]: Block storage service update volume status from reserved to available Message-ID: <11f602803604a655e1be5d8cc05383b4@uvic.ca> Hello there, Hope everything is going well. I would like to know if there is any method that could update the volume status or reset its state. While we creating volumes use the block storage service or creating vms with volumes use the compute service, sometimes we got volumes stuck in creating/deleteing/attaching/reserved state. And we couldn't remove them or reset their state without an admin account even we own the project. The way we create volumes and boot vms is like the following: # create the volume cv = cinder.create_volume(name=bv_name, size=size, image_id=imageobj.id, volume_type=volume_type, is_bootable=True) # format mapping data bdm = [{'uuid': cv.id, 'source_type': 'volume', 'destination_type': 'volume', 'delete_on_termination': True, 'boot_index': 0}] # create the vm nova.create_server(name=hostname, image_id=imageobj.id, flavor_id=flavorl.id, key_name=key_name, block_device_mapping=bdm, user_data=format_userdata, networks=netid, security_groups=sec_groups) In the normal situation, everything works. But in the case of any network issue, the volume might stuck in the process of creating, deleting, or attaching. And if the volume got created successfully, when it tries to create the vm, the volume will be reserved for it, but if anything wrong happen when creating the vm or get timed out, the volume will be in the reserved stage forever. We would like to know if we could update the state or delete them without the admin account? We tried the command line tools 'openstack volume set --state available ' and 'cinder reset-state --state available ', but both got: Policy doesn't allow volume_extension:volume_admin_actions:reset_status to be performed. (HTTP 403) (Request-ID: req-b50236c3-5662-4cc0-8602-19e79e80219d) ERROR: Unable to reset the state for the specified entity(s). We are using the chameleon openstack cloud but we are not the admin user there, so wondering if there is any method that we could update the volume in our own project? Thanks and have a great day! Catherine -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue Sep 7 22:08:15 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 7 Sep 2021 15:08:15 -0700 Subject: =?utf-8?Q?Re=3A_=5Blists=2Eopenstack=2Eorg=E4=BB=A3=E5=8F=91=5D?= =?utf-8?Q?=5Bzun=5D=5Bcyborg=5D=5Bkuryr=5D_Edge_for_scientific_research_s?= =?utf-8?Q?ession_on_September_13_Edge_WG_meeting?= In-Reply-To: References: Message-ID: <5DB3E1B1-1D6A-4C0B-AB3D-FE33F0B88961@gmail.com> Hi Bailin, Thank you for sharing the links. Zun is the project in OpenStack that is supporting to run and manage containers directly from OpenStack without the need of Kubernetes. As the Chameleon project is using it to run their containerized workload and they also need hardware accelerators they integrated it with Cyborg. Many of their activities fall under the edge computing area and they are starting their collaboration with the OpenInfra Edge Computing group for this reason. As part of that work we are helping them to reach relevant communities and project teams where their requirements identified some gaps and I believe the Cyborg-Zun integration is one of these. They would like to upstream their work if the community finds value in it as it may or may not fall into the current scope of the respective projects. I hope that we can start to discuss some of this on the meeting next Monday and take next steps from there. I hope this helps a bit with the context and we can have a fruitful discussion next week. I will share the recording of the meeting as soon as it is available in case someone would not be able to make it and would like to check out the presentation and the discussion that follows. Thanks, Ildikó > On Sep 3, 2021, at 04:20, Brin Zhang(张百林) wrote: > > Hi Ildiko, > > Currently Cyborg and nova support interaction, we are not very familiar with zun yet, if possible, please provide some relevant information. You can refer to [1] for Cyborg related materials, and [2] for the interactive content of nova and cyborg (not yet merged). > > [1]https://docs.openstack.org/cyborg/latest/user/architecture.html > [2]https://review.opendev.org/c/openstack/cyborg/+/794549 > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/nova-cyborg-interaction.html > > > Bailin Zhang (brinzhang) > > > -----邮件原件----- > 发件人: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] > 发送时间: 2021年8月31日 22:39 > 收件人: openstack-discuss > 主题: [lists.openstack.org代发][zun][cyborg][kuryr] Re: Edge for scientific research session on September 13 Edge WG meeting > > 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 ildiko.vancsa at gmail.com Tue Sep 7 22:11:20 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 7 Sep 2021 15:11:20 -0700 Subject: [zun][cyborg][kuryr] Edge for scientific research session on September 13 Edge WG meeting In-Reply-To: <2ff99838.2b86.17bb1528b2a.Coremail.joykechen@163.com> References: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> <2ff99838.2b86.17bb1528b2a.Coremail.joykechen@163.com> Message-ID: <9B16F1E4-A983-4C69-B890-1AED785AFF69@gmail.com> Dear Ke Chen, Thank you for the nice feedback and support. I hope the outcome of the discussion and activities that we will start next week will be to upstream this work item so that everyone can benefit from it. I will send you a reminder email about the meeting. See you next Monday! Best Regards, Ildikó > On Sep 4, 2021, at 07:59, 陈克 wrote: > > Hi Ildiko, > I'm a Cyborg core. I think it's cool to promote the integration of Cyborg and Zun. I'm happy to push > the whole thing if I could. Zun's PTL Shengqin Feng is my colleague. I suggest you send her and me a > reminder email before the meeting. > > Her Email: > feng.shengqin at zte.com.cn > > > Thanks, > Ke Chen > > > > > > > At 2021-08-31 22:39:01, "Ildiko Vancsa" wrote: > >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 ildiko.vancsa at gmail.com Tue Sep 7 22:20:11 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 7 Sep 2021 15:20:11 -0700 Subject: [zun][cyborg][kuryr][all] Edge for scientific research session on September 13 Edge WG meeting In-Reply-To: References: <315A37E8-8928-4225-B26F-A15ED0788E24@gmail.com> Message-ID: <24F010F0-5DE7-4455-8038-E23B9793FACD@gmail.com> Hi, It is a friendly reminder that the OpenInfra Edge Computing Group is having a joint session with the Chameleon project next Monday (September 13). 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 and the gaps they identified on the way along with the work they started to fill them. 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ó From zigo at debian.org Tue Sep 7 22:46:30 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 8 Sep 2021 00:46:30 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> Message-ID: On 9/7/21 3:39 PM, Jeremy Stanley wrote: > On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote: > [...] >> since we have pinned global requirements, will these new updates >> be included in the tests of older OpenStack releases? Is this >> really the case right now? > [...] > > They generally shouldn't, and most of the time can't realistically, > have their entries altered in stable branches of the > upper-constraints.txt file we use to pin dependency versions. To be > able to do so would prevent them from using new features of their > own dependencies in master branch development, since those would end > up also needing updates in the pinned list of transitive stable > branch constraints, which is exactly what we want to avoid. > > The workaround is to create a stable branch of the repository from > the last version which was tagged during the cycle for the release > which needs a fix to that independent deliverable backported. Those > cases are rare, and basically what you would include as a stable > distro package update for that coordinated release series anyway. > Hi, Thanks for your insights. Basically, what you're writing above confirm what I thought: the release-independent components are in fact not really release-independent, and are bound to a specific release of OpenStack. Most of the time, they aren't updated in the stable release CI. Therefore, it would probably be wise to try to minimize the amount of release-independent components to reflect this reality. In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena? I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI. Therefore, if possible, I would prefer clearer, easier to track, release-bound components with point release updates (though I understand that it may not be possible if that's too much work and OpenStack is getting understaffed...). Cheers, Thomas Goirand (zigo) From fungi at yuggoth.org Tue Sep 7 23:21:44 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 7 Sep 2021 23:21:44 +0000 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> Message-ID: <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: [...] > In fact, I was particularly confuse to realize that something like > taskflow was declared release-independent since Wallaby. Now, if > I'm told that it is loosely coupled with OpenStack, knowing that > it's a key component, I'm not sure what I should do. Should I get > taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it > safer to just upgrade it for Xena? > > I took Taskflow as an example (you can reply to me about Taskflow > in particular, but that's not the point I'm trying to make). But > it could have been something else (deptcollector? oslo.i18n?). > What I'm trying to say is that as a downstream consumer, it's from > hard to impossible to know what to do for the past OpenStack > releases regarding these release-independent components: should I > update them or not? It is unrealistic to hope that one can track > what component has been updated to a newer version in the stable > release CI. Specific examples are great actually, because it at least lets us try to formulate a specific answer and then reason about whether a similar answer can be generally applied to other related scenarios. So let's take taskflow in Wallaby and Xena: The closest thing we have to a recommendation for versions of "outside" dependencies (which is essentially what we treat release-independent deliverables as) is the upper-constraints.txt file on each branch of the openstack/requirements repository. In the case of taskflow, at the moment the stable/wallaby branch upper constraint for taskflow is 4.6.0, which is the version we indicate all OpenStack projects should test their stable/wallaby changes against. That entry was last updated by https://review.opendev.org/773620 which merged to the master branch of openstack/requirements in February, well before the coordinated Wallaby release. Even though the master (upcoming Xena coordinated release) upper-constraints.txt file lists taskflow===4.6.2, we don't test stable branch changes of OpenStack projects with that, only what will eventually become stable/xena once the Xena cycle concludes. > Therefore, if possible, I would prefer clearer, easier to track, > release-bound components with point release updates (though I > understand that it may not be possible if that's too much work and > OpenStack is getting understaffed...). It seems like what you're asking for is this: https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-constraints.txt Or rather, that's the closest thing we have to what I think you're requesting. If you follow the commit history of that file, you'll see recent updates for it on the stable/wallaby branch do consist almost entirely of stable point releases of cycle-oriented projects: https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upper-constraints.txt Does this help narrow the scope of concern to the point where we can better reason about the problems or challenges you're facing? -- 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 ildiko.vancsa at gmail.com Tue Sep 7 23:22:42 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 7 Sep 2021 16:22:42 -0700 Subject: Edge sessions at the upcoming PTG Message-ID: Hi, I’m reaching out to you to share the agenda of the OpenInfra Edge Computing Group that we put together for the upcoming PTG. I would like to invite everyone who is interested in discussing edge challenges and finding solutions! We summarized our plans for the event in a short blog post to give some context to each of the topic that we picked to discuss in details. We picked key areas like security, networking, automation and tools, containers and more: https://superuser.openstack.org/articles/the-project-teams-gathering-is-coming-lets-talk-edge/ Our etherpad for the sessions: https://etherpad.opendev.org/p/ecg-ptg-october-2021 Please let me know if you have any questions about the agenda or topics. Thanks and Best Regards, Ildikó From zhangbailin at inspur.com Wed Sep 8 00:15:36 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Wed, 8 Sep 2021 00:15:36 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1benVuXVtjeWJv?= =?utf-8?B?cmddW2t1cnlyXSBFZGdlIGZvciBzY2llbnRpZmljIHJlc2VhcmNoIHNlc3Np?= =?utf-8?Q?on_on_September_13_Edge_WG_meeting?= In-Reply-To: <5DB3E1B1-1D6A-4C0B-AB3D-FE33F0B88961@gmail.com> References: <5DB3E1B1-1D6A-4C0B-AB3D-FE33F0B88961@gmail.com> Message-ID: <360c63346cfd44fca42eaa744c84ef8d@inspur.com> > I will share the recording of the meeting as soon as it is available in case someone would not be able to make it and would like to check out the presentation and the discussion that follows. Thanks for you will share of the record, at 1300UTC I have another meeting (start 1100UTC), if I can end up that meeting earlier, I will join this meeting ^^ brinzhang -----邮件原件----- 发件人: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] 发送时间: 2021年9月8日 6:08 收件人: Brin Zhang(张百林) 抄送: openstack-discuss at lists.openstack.org; xin-ran.wang at intel.com 主题: Re: [lists.openstack.org代发][zun][cyborg][kuryr] Edge for scientific research session on September 13 Edge WG meeting Hi Bailin, Thank you for sharing the links. Zun is the project in OpenStack that is supporting to run and manage containers directly from OpenStack without the need of Kubernetes. As the Chameleon project is using it to run their containerized workload and they also need hardware accelerators they integrated it with Cyborg. Many of their activities fall under the edge computing area and they are starting their collaboration with the OpenInfra Edge Computing group for this reason. As part of that work we are helping them to reach relevant communities and project teams where their requirements identified some gaps and I believe the Cyborg-Zun integration is one of these. They would like to upstream their work if the community finds value in it as it may or may not fall into the current scope of the respective projects. I hope that we can start to discuss some of this on the meeting next Monday and take next steps from there. I hope this helps a bit with the context and we can have a fruitful discussion next week. I will share the recording of the meeting as soon as it is available in case someone would not be able to make it and would like to check out the presentation and the discussion that follows. Thanks, Ildikó > On Sep 3, 2021, at 04:20, Brin Zhang(张百林) wrote: > > Hi Ildiko, > > Currently Cyborg and nova support interaction, we are not very familiar with zun yet, if possible, please provide some relevant information. You can refer to [1] for Cyborg related materials, and [2] for the interactive content of nova and cyborg (not yet merged). > > [1]https://docs.openstack.org/cyborg/latest/user/architecture.html > [2]https://review.opendev.org/c/openstack/cyborg/+/794549 > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/nova-cyborg-interaction.html > > > Bailin Zhang (brinzhang) > > > -----邮件原件----- > 发件人: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] > 发送时间: 2021年8月31日 22:39 > 收件人: openstack-discuss > 主题: [lists.openstack.org代发][zun][cyborg][kuryr] Re: Edge for scientific research session on September 13 Edge WG meeting > > 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 joshua.hesketh at gmail.com Wed Sep 8 04:39:38 2021 From: joshua.hesketh at gmail.com (Joshua Hesketh) Date: Wed, 8 Sep 2021 14:39:38 +1000 Subject: Fwd: linux.conf.au 2022 - Call for Sessions now open! In-Reply-To: References: Message-ID: Hello all, Firstly sorry if this isn't the right list for this sort of content. While I've continued to lurk in the OpenStack community I haven't been engaged in a number of years sadly (and missing ya'll!). Nonetheless, linux.conf.au 2022 is coming soon as an online event. This is your unique opportunity to speak at a conference that would otherwise require some 24+ hours of travel for a lot of folk. The Call For Proposals is currently open until Sunday the 12th (it was extended) and it would be great to see some open infrastructure talks (Ansible, OpenStack, Kubernetes, zuul, Airship, etc etc). Read on for more information or let me know if you have any questions. Regardless if you submit a session it is also a great opportunity to attend a world class open source conference remotely! Cheers, Josh -------- Forwarded Message -------- Subject: linux.conf.au 2022 - Call for Sessions now open! Date: Tue, 10 Aug 2021 08:07:01 +1000 From: linux.conf.au Announcements Reply-To: lca-announce at lists.linux.org.au To: LCA Announce , Linux Aus The linux.conf.au 2022 Call for Sessions is now open. It will stay open until 11:59pm 5 September 2021 Anywhere on Earth (AoE). The theme for 2022 is 'community'. After the challenges of the past year, our community has explored ways to rebuild the connections we were used to having face-to-face. Many Open Source communities already had their roots online, so how can this be applied to other areas, and how can we keep people interested as they shift to living even more of their lives online? How can we keep in contact with connections in other countries in a virtual way? If you have ideas or developments you'd like to share with the open source community at linux.conf.au, we'd love to hear from you. ## Call for Sessions The main conference runs on Saturday 15 and Sunday 16 January, with multiple streams catering for a wide range of interest areas. We invite you to submit a session proposal on a topic you are familiar with via our proposals portal at https://lca2022.linux.org.au/programme/proposals/. Talks are 45 minute presentations on a single topic presented in lecture format. Each accepted talk will receive one ticket to attend the conference. ## Call for Miniconfs We are pleased to announce we will again have four Miniconfs on the first day, Friday 14 January 2022. These are: * GO GLAM meets Community * Kernel * Open Hardware * System Administration Based on feedback over a few years, we will be introducing two major changes for Miniconfs in 2022: all presentations will be 30 minutes long, and each accepted presentation will receive one ticket to the conference. The Call for Miniconf Sessions is now open on our website, so we encourage you to submit your proposal today. Check out our Miniconfs page at https://lca2022.linux.org.au/programme/miniconfs/ for more information. ## No need to book flights or hotels Don't forget: the conference will be an online, virtual experience. This means our speakers will be beaming in from their own homes or workplaces. The organising team will be able to help speakers with their tech set-up. Each accepted presenter will have a tech check prior to the event to smooth out any difficulties and there will be an option to pre-record presentations. ## Introducing LCA Local We know many of you have missed the experience of a face-to-face conference and in 2022 we are launching LCA Local. While our conference will be online, we are inviting people to join others in their local area and participate in the conference together. More information and an expression of interest form for LCA Local will be released soon. ## Have you got an idea? You can find out how to submit your session proposals at https://lca2022.linux.org.au/programme/proposals/. If you have any other questions, you can contact us via email at contact at lca2022.linux.org.au. The session selection committee is looking forward to reading your submissions. We would also like to thank them for coming together and volunteering their time to help put this conference together. linux.conf.au 2022 Organising Team ---- Read this online at https://lca2022.linux.org.au/news/call-for-sessions/ _______________________________________________ lca-announce mailing list lca-announce at lists.linux.org.au http://lists.linux.org.au/mailman/listinfo/lca-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Wed Sep 8 05:05:48 2021 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Wed, 8 Sep 2021 10:35:48 +0530 Subject: [sdk]: Block storage service update volume status from reserved to available In-Reply-To: <11f602803604a655e1be5d8cc05383b4@uvic.ca> References: <11f602803604a655e1be5d8cc05383b4@uvic.ca> Message-ID: Hi, On Wed, Sep 8, 2021 at 1:02 AM dmeng wrote: > Hello there, > > Hope everything is going well. > > I would like to know if there is any method that could update > the volume status or reset its state. While we creating volumes use the > block storage service or creating vms with volumes use the compute service, > sometimes we got volumes stuck in creating/deleteing/attaching/reserved > state. And we couldn't remove them or reset their state without an admin > account even we own the project. The way we create volumes and boot vms is > like the following: > > # create the volume > cv = cinder.create_volume(name=bv_name, size=size, image_id=imageobj.id, volume_type=volume_type, is_bootable=True) > # format mapping data > bdm = [{'uuid': cv.id, 'source_type': 'volume', 'destination_type': 'volume', 'delete_on_termination': True, 'boot_index': 0}] > # create the vm > nova.create_server(name=hostname, image_id=imageobj.id, flavor_id=flavorl.id, key_name=key_name, block_device_mapping=bdm, user_data=format_userdata, networks=netid, security_groups=sec_groups) > > In the normal situation, everything works. But in the case of any network issue, the volume might stuck in the process of creating, deleting, or attaching. And if the volume got created successfully, when it tries to create the vm, the volume will be reserved for it, but if anything wrong happen when creating the vm or get timed out, the volume will be in the reserved stage forever. We would like to know if we could update the state or delete them without the admin account? > > We tried the command line tools 'openstack volume set --state available ' and 'cinder reset-state --state available ', but both got: > Policy doesn't allow volume_extension:volume_admin_actions:reset_status to be performed. (HTTP 403) (Request-ID: req-b50236c3-5662-4cc0-8602-19e79e80219d) > ERROR: Unable to reset the state for the specified entity(s). > > For the specific case where a volume is stuck in reserved state and the above code uses cinder's new attachments API, you can use* ``cinder --os-volume-api-version 3.27 attachment-list`` *to list all attachments for volumes and if there exists attachment(s) for your volume, you can delete them via the command *``cinder --os-volume-api-version 3.27 attachment-delete ``* > We are using the chameleon openstack cloud but we are not the admin user there, so wondering if there is any method that we could update the volume in our own project? > > Thanks and have a great day! > Catherine > > Thanks and regards Rajat Dhasmana -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Sep 8 08:27:50 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 8 Sep 2021 10:27:50 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> Message-ID: <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> On 9/8/21 1:21 AM, Jeremy Stanley wrote: > On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: > [...] >> In fact, I was particularly confuse to realize that something like >> taskflow was declared release-independent since Wallaby. Now, if >> I'm told that it is loosely coupled with OpenStack, knowing that >> it's a key component, I'm not sure what I should do. Should I get >> taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it >> safer to just upgrade it for Xena? >> >> I took Taskflow as an example (you can reply to me about Taskflow >> in particular, but that's not the point I'm trying to make). But >> it could have been something else (deptcollector? oslo.i18n?). >> What I'm trying to say is that as a downstream consumer, it's from >> hard to impossible to know what to do for the past OpenStack >> releases regarding these release-independent components: should I >> update them or not? It is unrealistic to hope that one can track >> what component has been updated to a newer version in the stable >> release CI. > > Specific examples are great actually, because it at least lets us > try to formulate a specific answer and then reason about whether a > similar answer can be generally applied to other related scenarios. > So let's take taskflow in Wallaby and Xena: > > The closest thing we have to a recommendation for versions of > "outside" dependencies (which is essentially what we treat > release-independent deliverables as) is the upper-constraints.txt > file on each branch of the openstack/requirements repository. In > the case of taskflow, at the moment the stable/wallaby branch upper > constraint for taskflow is 4.6.0, which is the version we indicate > all OpenStack projects should test their stable/wallaby changes > against. That entry was last updated by > https://review.opendev.org/773620 which merged to the master branch > of openstack/requirements in February, well before the coordinated > Wallaby release. Ok, so your recommendation is that, for each and every component that is marked release-independent, I should be checking the global requirements. I just wrote that this is unrealistic that a human does such a check. If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack with me together in Debian) wrote this: https://salsa.debian.org/openstack-team/debian/os-version-checker This VersionStatus.py checks for what's in https://releases.openstack.org/, for example in https://releases.openstack.org/xena/index.html for the Xena upcoming release. The result output of the os-version-checker is this page: http://osbpo.debian.net/deb-status/ Thanks to this page, anyone can know the status of OpenStack packaging on all the different branches we maintain. If you look at it right now, you'll notice that we're up-to-date, as we packaged all non-clients and all clients library, but we didn't package new versions of the puppet manifests yet (I'm waiting for the RCs to do that). If you click on the buster-victoria button, and look for Taskflow, you'll see that it's up-to-date. If you click on bullseye-xena, and search for Taskflow, you will ... find nothing! That's because taskflow doesn't appear in https://releases.openstack.org/xena/index.html since it is release-independent. As a result, I'm left with no other choice than being very careful and manually check the global-requirements. Every check that is supposed to be done by a human isn't reliable. It'd be nice if I had a way to automatically check for this. The thing is, the global-requirements is full of information, some of it not relevant to my own use case, and it's hard to check automatically. First of all, because the Python module names as in PyPi, do not necessarily match the package names. Also, because some artifacts are not relevant to Debian. For example, I have no use of many TripleO stuff, and some services are simply not packaged in Debian. In an ideal world, we'd have an API to check for all of this, rather than digging through the release HTML pages. > It seems like what you're asking for is this: > > https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-constraints.txt > > Or rather, that's the closest thing we have to what I think you're > requesting. If you follow the commit history of that file, you'll > see recent updates for it on the stable/wallaby branch do consist > almost entirely of stable point releases of cycle-oriented projects: > > https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upper-constraints.txt > > Does this help narrow the scope of concern to the point where we can > better reason about the problems or challenges you're facing? Unfortunately, while it is part of the answer, due to what I explained just above, it is very hard to exploit the available data without a real, long effort on our side to fix this. :/ One solution could probably be for *US* (downstream distros) to write some kind of API as I just wrote, and make it available for everyone on releases.openstack.org. Are Red Hat people also interested by such an effort? Any pointer where we should attempt to propose patches? Cheers, Thomas Goirand (zigo) From hberaud at redhat.com Wed Sep 8 09:31:31 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 8 Sep 2021 11:31:31 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> Message-ID: Le mer. 8 sept. 2021 à 10:29, Thomas Goirand a écrit : > On 9/8/21 1:21 AM, Jeremy Stanley wrote: > > On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: > > [...] > >> In fact, I was particularly confuse to realize that something like > >> taskflow was declared release-independent since Wallaby. Now, if > >> I'm told that it is loosely coupled with OpenStack, knowing that > >> it's a key component, I'm not sure what I should do. Should I get > >> taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it > >> safer to just upgrade it for Xena? > >> > >> I took Taskflow as an example (you can reply to me about Taskflow > >> in particular, but that's not the point I'm trying to make). But > >> it could have been something else (deptcollector? oslo.i18n?). > >> What I'm trying to say is that as a downstream consumer, it's from > >> hard to impossible to know what to do for the past OpenStack > >> releases regarding these release-independent components: should I > >> update them or not? It is unrealistic to hope that one can track > >> what component has been updated to a newer version in the stable > >> release CI. > > > > Specific examples are great actually, because it at least lets us > > try to formulate a specific answer and then reason about whether a > > similar answer can be generally applied to other related scenarios. > > So let's take taskflow in Wallaby and Xena: > > > > The closest thing we have to a recommendation for versions of > > "outside" dependencies (which is essentially what we treat > > release-independent deliverables as) is the upper-constraints.txt > > file on each branch of the openstack/requirements repository. In > > the case of taskflow, at the moment the stable/wallaby branch upper > > constraint for taskflow is 4.6.0, which is the version we indicate > > all OpenStack projects should test their stable/wallaby changes > > against. That entry was last updated by > > https://review.opendev.org/773620 which merged to the master branch > > of openstack/requirements in February, well before the coordinated > > Wallaby release. > > Ok, so your recommendation is that, for each and every component that is > marked release-independent, I should be checking the global > requirements. I just wrote that this is unrealistic that a human does > such a check. > > If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack > with me together in Debian) wrote this: > > https://salsa.debian.org/openstack-team/debian/os-version-checker > > This VersionStatus.py checks for what's in > https://releases.openstack.org/, for example in > https://releases.openstack.org/xena/index.html for the Xena upcoming > release. > > The result output of the os-version-checker is this page: > > http://osbpo.debian.net/deb-status/ > > Thanks to this page, anyone can know the status of OpenStack packaging > on all the different branches we maintain. If you look at it right now, > you'll notice that we're up-to-date, as we packaged all non-clients and > all clients library, but we didn't package new versions of the puppet > manifests yet (I'm waiting for the RCs to do that). > > If you click on the buster-victoria button, and look for Taskflow, > you'll see that it's up-to-date. If you click on bullseye-xena, and > search for Taskflow, you will ... find nothing! That's because taskflow > doesn't appear in https://releases.openstack.org/xena/index.html since > it is release-independent. As a result, I'm left with no other choice > than being very careful and manually check the global-requirements. > > Every check that is supposed to be done by a human isn't reliable. It'd > be nice if I had a way to automatically check for this. The thing is, > the global-requirements is full of information, some of it not relevant > to my own use case, and it's hard to check automatically. First of all, > because the Python module names as in PyPi, do not necessarily match the > package names. Also, because some artifacts are not relevant to Debian. > For example, I have no use of many TripleO stuff, and some services are > simply not packaged in Debian. > > In an ideal world, we'd have an API to check for all of this, rather > than digging through the release HTML pages. > > > It seems like what you're asking for is this: > > > > > https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-constraints.txt > > > > Or rather, that's the closest thing we have to what I think you're > > requesting. If you follow the commit history of that file, you'll > > see recent updates for it on the stable/wallaby branch do consist > > almost entirely of stable point releases of cycle-oriented projects: > > > > > https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upper-constraints.txt > > > > Does this help narrow the scope of concern to the point where we can > > better reason about the problems or challenges you're facing? > > Unfortunately, while it is part of the answer, due to what I explained > just above, it is very hard to exploit the available data without a > real, long effort on our side to fix this. :/ > > One solution could probably be for *US* (downstream distros) to write > some kind of API as I just wrote, and make it available for everyone on > releases.openstack.org. Are Red Hat people also interested by such an > effort? Any pointer where we should attempt to propose patches? > An API seems quite a good idea I'm ok to give help on this point with my upstream cap and my Red Hat cap. As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic. However you should notice that we are near Xena's deadline, and, so, for now, I don't think that we will have the time to work on this topic. Also, although I'm volunteering to help, you should notice that the release team will have another PTL for Y, so, the lead of this topic is at the discretion of my replacant. I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams). Hopefully it will help us. [1] https://etherpad.opendev.org/p/xena-relmgt-tracking [2] https://governance.openstack.org/tc/goals/ > Cheers, > > Thomas Goirand (zigo) > > -- 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 lyarwood at redhat.com Wed Sep 8 09:56:45 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Wed, 8 Sep 2021 10:56:45 +0100 Subject: Error adding a Plain Volume created through GUI to Instance In-Reply-To: <20210906094103.sn4bn6qb4sab3p2m@localhost> References: <20210906094103.sn4bn6qb4sab3p2m@localhost> Message-ID: <20210908095645.droxjr6bmlof4tfd@lyarwood-laptop.usersys.redhat.com> On 06-09-21 11:41:03, Gorka Eguileor wrote: > On 06/09, KK CHN wrote: > > ExecutionError: Unexpected error while running command. > > Command: rbd map volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 --pool volumes > > --id volumes --mon_host 10.236.223.131:6789 --mon_host 10.236.223.132:6789 > > Exit code: 6 > > Stdout: 'RBD image feature set mismatch. You can disable features > > unsupported by the kernel with "rbd feature disable > > volumes/volume-4dcb78d5-e0ce-4bfc-95ae-36a4417c35d8 journaling".\nIn some > > cases useful info is found in syslog - try "dmesg | tail".\n' > > Stderr: 'rbd: sysfs write failed\nrbd: map failed: (6) No such device or > > address\n' > > > > I am trying to add a 20 GB plain volume created through Horizon GUI to an > > existing Windows 2012 R VM running with VirtIO drivers installed. But this > > volume adding results in the error as shown above, > > > > trace tells to fix it by rbd feature disable .. what is the > > permanent fix for this issue ? and why it happens ? > > > > ( OpenStack Ussuri, Glance, Ceph , qemu-kvm) > > > > root at ctrl1:/home/cloud# ceph --version > > ceph version 14.2.19 (bb796b9b5bab9463106022eef406373182465d11) nautilus > > (stable) > > root at ctrl1:/home/cloud# > > Hi, > > Usually RBD volumes are directly attached on the hypervisor, but there > was an encryption performance issue [1] so nova and os-brick added > support to attaching these volumes to the host and then use them on the > VM. > > Attaching volumes on the host uses the krbd module, whereas attaching > them to the hypervisor directly uses librbd, with the first one lagging > in terms of Ceph features. > > The issue you are facing is that the images in RBD are being created > with features that are not supported by krbd. > > Fixes are: > > - Disable those features in your ceph configuration file (usually > /etc/ceph/ceph.conf) > > Under [global] section add: > rbd default features = 3 > > - Change "[workarounds]rbd_volume_local_attach" to False in Nova's > config. > > Cheers, > Gorka. > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1762765 Yup thanks Gorka and just for awareness this workaround and the associated disable_native_luksv1 workaround have been removed in the Xena release as the underlying performance issues have been resolved AFAIK: workarounds: Remove rbd_volume_local_attach https://review.opendev.org/c/openstack/nova/+/805648 workarounds: Remove disable_native_luksv1 https://review.opendev.org/c/openstack/nova/+/805647/ 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 chkumar at redhat.com Wed Sep 8 10:00:14 2021 From: chkumar at redhat.com (Chandan Kumar) Date: Wed, 8 Sep 2021 15:30:14 +0530 Subject: [patrole][qa] Proposing Soniya Vyas to Patrole core In-Reply-To: <17bc1bcebec.d7cc6895149770.7494147722877953142@ghanshyammann.com> References: <17bc1bcebec.d7cc6895149770.7494147722877953142@ghanshyammann.com> Message-ID: On Wed, Sep 8, 2021 at 1:03 AM Ghanshyam Mann wrote: > > ---- On Tue, 07 Sep 2021 14:15:04 -0500 Martin Kopec wrote ---- > > Hi all, > > > > Soniya Vyas (IRC: soniya29) is very enthusiastic about Patrole project and since she has been very helpful, I'd like to propose her for Patrole core. > > > > You can vote/feedback on this email. If no objections within a week, I'll add her to the core list. > > +1, she has been very helpful in Patrole project. +1, Thank you Sonia for all the great work. Thanks, Chandan Kumar From lyarwood at redhat.com Wed Sep 8 10:57:00 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Wed, 8 Sep 2021 11:57:00 +0100 Subject: [sdk]: Block storage service update volume status from reserved to available In-Reply-To: References: <11f602803604a655e1be5d8cc05383b4@uvic.ca> Message-ID: <20210908105700.qfw43cd2o757rpv3@lyarwood-laptop.usersys.redhat.com> On 08-09-21 10:35:48, Rajat Dhasmana wrote: > Hi, > > On Wed, Sep 8, 2021 at 1:02 AM dmeng wrote: > > > Hello there, > > > > Hope everything is going well. > > > > I would like to know if there is any method that could update > > the volume status or reset its state. While we creating volumes use the > > block storage service or creating vms with volumes use the compute service, > > sometimes we got volumes stuck in creating/deleteing/attaching/reserved > > state. And we couldn't remove them or reset their state without an admin > > account even we own the project. The way we create volumes and boot vms is > > like the following: > > > > # create the volume > > cv = cinder.create_volume(name=bv_name, size=size, image_id=imageobj.id, volume_type=volume_type, is_bootable=True) > > # format mapping data > > bdm = [{'uuid': cv.id, 'source_type': 'volume', 'destination_type': 'volume', 'delete_on_termination': True, 'boot_index': 0}] > > # create the vm > > nova.create_server(name=hostname, image_id=imageobj.id, flavor_id=flavorl.id, key_name=key_name, block_device_mapping=bdm, user_data=format_userdata, networks=netid, security_groups=sec_groups) > > > > In the normal situation, everything works. But in the case of any > > network issue, the volume might stuck in the process of creating, > > deleting, or attaching. And if the volume got created successfully, > > when it tries to create the vm, the volume will be reserved for it, > > but if anything wrong happen when creating the vm or get timed out, > > the volume will be in the reserved stage forever. We would like to > > know if we could update the state or delete them without the admin > > account? You need to delete the ERROR'd out instance, this will delete the volume attachment in Cinder moving the volume to available again. Nova does this to ensure another instance doesn't take this volume as the user might request that the instance is rebuilt to workaround whatever issue they encountered during the initial build. > > We tried the command line tools 'openstack volume set --state > > available ' and 'cinder reset-state --state available > > ', but both got: Policy doesn't allow > > volume_extension:volume_admin_actions:reset_status to be performed. > > (HTTP 403) (Request-ID: req-b50236c3-5662-4cc0-8602-19e79e80219d) > > ERROR: Unable to reset the state for the specified entity(s). > > > > For the specific case where a volume is stuck in reserved state and the > above code uses cinder's new attachments API, you can use* ``cinder > --os-volume-api-version 3.27 attachment-list`` *to list all attachments for > volumes and if there exists attachment(s) for your volume, you can delete > them via the command *``cinder --os-volume-api-version 3.27 > attachment-delete ``* As above we retain the volume attachment on build failures so either rebuild the instance or delete it to free up the volume again. 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 eblock at nde.ag Wed Sep 8 11:02:25 2021 From: eblock at nde.ag (Eugen Block) Date: Wed, 08 Sep 2021 11:02:25 +0000 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> <20210906144401.Horde.7j4UyxpB4wl0f5RgwX1Y0FD@webmail.nde.ag> Message-ID: <20210908110225.Horde.VCbq8x0RD-cMYvSMHmMvJOr@webmail.nde.ag> Great that you got it working. The dashboard logs should tell you want went wrong, e.g. in /var/log/apache2/openstack-dashboard-error_log. It's probably some role missing for your user, but you'll find details in the logs. Zitat von Michel Niyoyita : > Hello team, > > Now I am able to create containers and upload objects in the openstack CLI > side using the following commands: > (kolla-open1) stack at kolla-open1:~$ swift -V 1.0 -A > http://ceph-mon2:8080/auth/v1 -U operator:swift -K opswift post > my-container3 > (kolla-open1) stack at kolla-open1:~$ swift -V 1.0 -A > http://ceph-mon2:8080/auth/v1 -U operator:swift -K opswift upload > my-container3 michel.txt > > above commands are successful and containers and their objects are stored > in ceph RGW default pool which replace swift . > > The issues I remain with is that once I try to access the object store on > horizon and click on containers it immediately disconnect hoizon to the > login status. > [image: image.png] > [image: image.png] > > Kindly help and advise > > Michel > > > > On Mon, Sep 6, 2021 at 4:50 PM Eugen Block wrote: > >> It's hard to tell what is wrong with your setup, I don't really use >> mine but this was the last working config I had to be able to create >> swift containers directly in RGW: >> >> ---snip--- >> # ceph.conf: >> >> [client.rgw.ses6-mon1] >> rgw frontends = "beast port=80" >> rgw dns name = ses6-mon1.example.com >> rgw enable usage log = true >> >> rgw thread pool size = 512 >> rgw keystone api version = 3 >> rgw keystone url = http://control-node.example.com:5000 >> >> rgw keystone admin user = rgw >> rgw keystone admin password = **** >> rgw keystone admin domain = default >> rgw keystone admin project = service >> rgw keystone accepted roles = admin,Member,_member_,member >> rgw keystone verify ssl = false >> rgw s3 auth use keystone = true >> rgw keystone revocation interval = 0 >> >> >> # User role (I don't think admin is required) >> >> openstack role add --user rgw --project 9e8a67da237a4b26afb2819d2dea2219 >> admin >> >> >> # Create keystone endpoints >> >> openstack endpoint create --region RegionOne swift admin >> "http://ses6-mon1.example.com:80/swift/v1" >> openstack endpoint create --region RegionOne swift internal >> "http://ses6-mon1.example.com:80/swift/v1" >> openstack endpoint create --region RegionOne swift public >> "http://ses6-mon1.example.com:80/swift/v1" >> >> >> # Create container and files >> >> openstack container create swift1 >> +---------+-----------+---------------------------------------------------+ >> | account | container | x-trans-id | >> +---------+-----------+---------------------------------------------------+ >> | v1 | swift1 | tx000000000000000000001-0060b4ba48-d724dc-default | >> +---------+-----------+---------------------------------------------------+ >> >> openstack object create --name file1 swift1 chef-client.log >> +--------+-----------+----------------------------------+ >> | object | container | etag | >> +--------+-----------+----------------------------------+ >> | file1 | swift1 | 56a1ed3b201c1e753bcbe80c640349f7 | >> +--------+-----------+----------------------------------+ >> ---snip--- >> >> >> You are mixing dns names and IP addresses, I can't tell if that's a >> problem but it probably should work, I'm not sure. Compared to my >> ceph.conf these are the major differences: >> >> rgw keystone verify ssl = false >> rgw s3 auth use keystone = true >> rgw keystone revocation interval = 0 >> >> And I don't use rgw_keystone_token_cache_size. Maybe try again with >> the options I use. >> >> >> Zitat von Michel Niyoyita : >> >> > Hello, >> > >> > I am trying to replace swift by RGW as backend storage but I failed once >> I >> > try to post a container in the OpenStack side however, all interfaces are >> > configured (admin, public and internal). but Once I post from RGW host it >> > is created . Another issue is that object storage does not appear on the >> > horizon dashboard . I have deployed openstack all-in-one using >> > kolla-ansible and Os is ubuntu >> > >> > (kolla-open1) stack at kolla-open1:~$ swift -v post myswift >> > Container POST failed: http://ceph-osd3:8080/swift/v1/myswift 401 >> > Unauthorized b'AccessDenied' >> > Failed Transaction ID: tx000000000000000000008-006135dcbd-87d63-default >> > >> > (kolla-open1) stack at kolla-open1:~$ swift list >> > Account GET failed: http://ceph-osd3:8080/swift/v1?format=json 401 >> > Unauthorized [first 60 chars of response] >> > b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000c-' >> > Failed Transaction ID: tx00000000000000000000c-006135de42-87d63-default >> > >> > Kindly help to solve the issue >> > >> > Michel >> > >> > On Thu, Sep 2, 2021 at 4:28 PM Alex Schultz wrote: >> > >> >> The swift docs are a bit out of date as they still reference python2 >> >> despite python3 being supported for some time now. Replace python- with >> >> python3- and try again. >> >> >> >> >> >> On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita >> wrote: >> >> >> >>> >> >>> >> >>> ---------- Forwarded message --------- >> >>> From: Michel Niyoyita >> >>> Date: Thu, Sep 2, 2021 at 12:17 PM >> >>> Subject: Fwd: [ceph-users] Re: Replacing swift with RGW >> >>> To: >> >>> >> >>> >> >>> >> >>> >> >>> ---------- Forwarded message --------- >> >>> From: Eugen Block >> >>> Date: Thu, Sep 2, 2021 at 10:39 AM >> >>> Subject: Re: [ceph-users] Re: Replacing swift with RGW >> >>> To: Michel Niyoyita >> >>> >> >>> >> >>> You should continue this thread on the openstack-discuss mailing list >> >>> (openstack-discuss at lists.openstack.org) since this is not a ceph >> issue. >> >>> I'm not familiar with kolla and I don't know the requirements to >> >>> install openstack-swift, you'll need to ask the openstack community. >> >>> >> >>> >> >>> Zitat von Michel Niyoyita : >> >>> >> >>> > Below are errors I am getting once I try to run swift commands . the >> >>> second >> >>> > one is the error I get once try to install python-swiftclient >> >>> > >> >>> > (kolla-open) [stack at kolla-open ~]$ swift -v stat >> >>> > -bash: swift: command not found >> >>> > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install >> >>> python-swiftclient >> >>> > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 >> 09:21:53 >> >>> AM >> >>> > CAT. >> >>> > No match for argument: python-swiftclient >> >>> > Error: Unable to find a match: python-swiftclient >> >>> > (kolla-open) [stack at kolla-open ~]$ >> >>> > >> >>> > Waiting for your help >> >>> > >> >>> > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: >> >>> > >> >>> >> I can't tell for sure, but yes, I believe you need the >> openstack-swift >> >>> >> package (with dependencies). What errors do you get? The more >> >>> >> information you share the better people can help. >> >>> >> >> >>> >> >> >>> >> Zitat von Michel Niyoyita : >> >>> >> >> >>> >> > I tried to install "sudo yum -y install python-swiftclient" on >> >>> openstack >> >>> >> > side but fails . are there openastack-shwift packages which are >> >>> needed? >> >>> >> > if are there please help me to get . may be also it is the cause >> I >> >>> am >> >>> >> > failing to run swift command on openstack cli side. >> >>> >> > >> >>> >> > thank you for your continued support. >> >>> >> > >> >>> >> > Micheal >> >>> >> > >> >>> >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: >> >>> >> > >> >>> >> >> I only configured the endpoints for the clients to directly >> access >> >>> the >> >>> >> >> RGWs, but you'll probably need to install the openstack-swift >> >>> package. >> >>> >> >> Or have you done that already? >> >>> >> >> >> >>> >> >> >> >>> >> >> Zitat von Michel Niyoyita : >> >>> >> >> >> >>> >> >> > Thank you Eugen for your prompt response. >> >>> >> >> > >> >>> >> >> > Now the commands provided work. but I am not finding the object >> >>> >> storage >> >>> >> >> on >> >>> >> >> > the horizon dashboard , but it appears in the system >> information >> >>> >> >> services. >> >>> >> >> > [image: image.png] >> >>> >> >> > so my question is how to configure it in order that it can >> appear >> >>> in >> >>> >> the >> >>> >> >> > dashboard . >> >>> >> >> > >> >>> >> >> > Michel >> >>> >> >> > >> >>> >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block >> wrote: >> >>> >> >> > >> >>> >> >> >> Sorry, one little detail slipped through, the '--region' flag >> >>> has to >> >>> >> >> >> be put before the 'service' name. The correct command would >> be: >> >>> >> >> >> >> >>> >> >> >> openstack endpoint create --region RegionOne swift admin >> >>> >> >> >> http://ceph-osd3:8080/swift/v1 >> >>> >> >> >> >> >>> >> >> >> and respectively for the other interfaces. >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> Zitat von Eugen Block : >> >>> >> >> >> >> >>> >> >> >> > Hi, >> >>> >> >> >> > >> >>> >> >> >> > this is not a ceph issue but your openstack cli command as >> the >> >>> >> error >> >>> >> >> >> > message states. >> >>> >> >> >> > >> >>> >> >> >> > Try one interface at a time: >> >>> >> >> >> > >> >>> >> >> >> > openstack endpoint create swift public >> >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >>> >> >> >> > openstack endpoint create swift admin >> >>> >> http://ceph-osd3:8080/swift/v1 >> >>> >> >> >> > --region RegionOne swift >> >>> >> >> >> > openstack endpoint create swift internal >> >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift >> >>> >> >> >> > >> >>> >> >> >> > >> >>> >> >> >> > Zitat von Michel Niyoyita : >> >>> >> >> >> > >> >>> >> >> >> >> Hello , >> >>> >> >> >> >> >> >>> >> >> >> >> Below are errors I am getting once I am trying to integrate >> >>> swift >> >>> >> >> with >> >>> >> >> >> >> Radosgateway. >> >>> >> >> >> >> >> >>> >> >> >> >> From openstack side once i try to endpoint which will point >> >>> to the >> >>> >> >> >> >> radosgateway : >> >>> >> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint >> >>> create >> >>> >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl >> >>> >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal >> >>> >> >> >> http://ceph-osd3:8080/swift/v1 >> >>> >> >> >> >> --region RegionOne swift >> >>> >> >> >> >> usage: openstack endpoint create [-h] [-f >> >>> >> >> {json,shell,table,value,yaml}] >> >>> >> >> >> >> [-c COLUMN] [--noindent] >> >>> [--prefix >> >>> >> >> >> PREFIX] >> >>> >> >> >> >> [--max-width ] >> >>> >> [--fit-width] >> >>> >> >> >> >> [--print-empty] [--region >> >>> >> >> ] >> >>> >> >> >> >> [--enable | --disable] >> >>> >> >> >> >> >> >>> >> >> >> >> openstack endpoint create: error: argument : >> >>> invalid >> >>> >> >> choice: >> >>> >> >> >> ' >> >>> >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', >> >>> 'public', >> >>> >> >> >> 'internal') >> >>> >> >> >> >> >> >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ >> >>> >> >> >> >> >> >>> >> >> >> >> below are my /etc/ceph/ceph.conf file : >> >>> >> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3] >> >>> >> >> >> >> rgw_dns_name = ceph-osd3 >> >>> >> >> >> >> host = ceph-osd3 >> >>> >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring >> >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log >> >>> >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 >> >>> num_threads=100 >> >>> >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 >> >>> >> >> >> >> rgw_keystone_admin_user=admin >> >>> >> >> >> >> rgw_keystone_admin_password=admin >> >>> >> >> >> >> rgw_keystone_admin_tenant=admin >> >>> >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator >> >>> >> >> >> >> rgw_keystone_token_cache_size=200 >> >>> >> >> >> >> rgw_keystone_revocation_interval=300 >> >>> >> >> >> >> >> >>> >> >> >> >> [client.rgw.ceph-osd3.rgw0] >> >>> >> >> >> >> host = ceph-osd3 >> >>> >> >> >> >> keyring = >> >>> /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring >> >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log >> >>> >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 >> >>> >> >> >> >> rgw thread pool size = 512 >> >>> >> >> >> >> >> >>> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with >> >>> 10.10.29.110 as >> >>> >> IP >> >>> >> >> >> >> >> >>> >> >> >> >> and 10.10.29.150 all-in-one IP >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> Please crosscheck where I might make mistake and try to >> >>> correct. >> >>> >> >> >> >> >> >>> >> >> >> >> Best regards >> >>> >> >> >> >> >> >>> >> >> >> >> Michel >> >>> >> >> >> >> >> >>> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < >> >>> >> >> >> etienne.menguy at croit.io> >> >>> >> >> >> >> wrote: >> >>> >> >> >> >> >> >>> >> >> >> >>> Hi, >> >>> >> >> >> >>> >> >>> >> >> >> >>> There are some information on Ceph documentation >> >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < >> >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . >> >>> >> >> >> >>> - Use keystone as auth for RGW >> >>> >> >> >> >>> - Create service and register your RGW as swift >> >>> >> >> >> >>> >> >>> >> >> >> >>> Étienne >> >>> >> >> >> >>> >> >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita < >> >>> micou12 at gmail.com> >> >>> >> >> wrote: >> >>> >> >> >> >>>> >> >>> >> >> >> >>>> Hello , >> >>> >> >> >> >>>> >> >>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using >> ceph >> >>> >> >> ansible >> >>> >> >> >> and >> >>> >> >> >> >>>> create sub user to access the created containers and >> would >> >>> like >> >>> >> to >> >>> >> >> >> >>> replace >> >>> >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on >> >>> >> >> configuration >> >>> >> >> >> to >> >>> >> >> >> >>> be >> >>> >> >> >> >>>> done in the OpenStack side in order to integrate those >> >>> >> services. I >> >>> >> >> >> have >> >>> >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu >> >>> 20.04. >> >>> >> and >> >>> >> >> >> ceph >> >>> >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 >> >>> >> >> >> >>>> >> >>> >> >> >> >>>> Kindly help for the configuration or documentation. >> >>> >> >> >> >>>> >> >>> >> >> >> >>>> Best Regards >> >>> >> >> >> >>>> >> >>> >> >> >> >>>> Michel >> >>> >> >> >> >>>> _______________________________________________ >> >>> >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io >> >>> >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >>> >> >> >> >>> >> >>> >> >> >> >>> _______________________________________________ >> >>> >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io >> >>> >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io >> >>> >> >> >> >>> >> >>> >> >> >> >> _______________________________________________ >> >>> >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >>> >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> _______________________________________________ >> >>> >> >> >> ceph-users mailing list -- ceph-users at ceph.io >> >>> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io >> >>> >> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> From zigo at debian.org Wed Sep 8 11:27:08 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 8 Sep 2021 13:27:08 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> Message-ID: On 9/8/21 11:31 AM, Herve Beraud wrote: > An API seems quite a good idea > > I'm ok to give help on this point with my upstream cap and my Red Hat cap. > > As release manager I added your proposition to our "things to changes" > on our release process and tools. > I think that it should be discussed first to see how to implement it and > how to host it. > I think that the technical details would be a transversal decision > between the infra team and the release team and the volunteers on this > topic. > > However you should notice that we are near Xena's deadline, and, so, for > now, I don't think that we will have the time to work on this topic. > Also,  although I'm volunteering to help, you should notice that the > release team will have another PTL for Y, so, the lead of this topic is > at the discretion of my replacant. > > I think a good starting point could be to design some specs or propose > some related goals, so, Thomas, maybe you could start by creating > something like that with your expectations. It will allow us to start > this topic, share our different feedback and our expectations on it (our > different viewpoints, at least from the release team, infra team, and > downstream/distros teams). > > Hopefully it will help us. Hi Herve, Thanks a lot for your enthusiasm, volunteering, and all. I very much agree that it's too late for Xena, though I wasn't even hoping for it that early. This was merely a suggestion. I will try to get my co-maintainer (Michal Arbet) in the loop so we can at least design the blue-print together. I also have to give this some thoughts myself before I can start. Cheers, Thomas Goirand (zigo) From ianyrchoi at gmail.com Wed Sep 8 11:56:50 2021 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Wed, 8 Sep 2021 20:56:50 +0900 Subject: [all][elections][ptl] Project Team Lead Election Conclusion and Results Message-ID: Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Barbican : Douglas Mendizábal * Blazar : Pierre Riteau * Cinder : Brian Rosmaita * Cloudkitty : Rafael Weingartner * Cyborg : Bailin Zhang * Designate : Michael Johnson * Ec2 Api : Andrey Pavlov * Freezer : ge cong * Glance : Abhishek Kekane * Horizon : Vishal Manchanda * Ironic : Iury Gregory Melo Ferreira * Kolla : Michal Nasiadka * Kuryr : Maysa de Macedo Souza * Magnum : Feilong Wang * Manila : Goutham Pacha Ravi * Masakari : Radosław Piliszek * Murano : Rong Zhu * Neutron : Lajos Katona * Nova : Sylvain Bauza * Octavia : Gregory Thiemonge * OpenStack Charms : Alex Kavanagh * Openstack Chef : Lance Albertson * OpenStack Helm : Gage Hugo * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Quality Assurance : Martin Kopec * Rally : Andrey Kurilin * Release Management : Elod Illes * Requirements : Matthew Thode * Senlin : XueFeng Liu * Solum : Rong Zhu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Matthias Runge * Tripleo : James Slagle * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : chen ke * Winstackers : Lucian Petrut * Zaqar : wang hao Elections: * Cyborg: https://civs1.civs.us/cgi-bin/results.pl?id=E_807146df7d6a1d3b Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Ian Y. Choi, on behalf of the OpenStack Technical Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Sep 8 12:07:25 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 8 Sep 2021 14:07:25 +0200 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> Message-ID: Openstack enter more and more in maintenance mode, with decreasing staffs, and reduced project activity which de facto lead us to this kind of situation, so this is a rational proposition. Automation and tooling is a big part of the solution to this problem. Great, thanks for the future blue-print. Do not hesitate to ping us either on IRC or by replying to this thread. Le mer. 8 sept. 2021 à 13:28, Thomas Goirand a écrit : > On 9/8/21 11:31 AM, Herve Beraud wrote: > > An API seems quite a good idea > > > > I'm ok to give help on this point with my upstream cap and my Red Hat > cap. > > > > As release manager I added your proposition to our "things to changes" > > on our release process and tools. > > I think that it should be discussed first to see how to implement it and > > how to host it. > > I think that the technical details would be a transversal decision > > between the infra team and the release team and the volunteers on this > > topic. > > > > However you should notice that we are near Xena's deadline, and, so, for > > now, I don't think that we will have the time to work on this topic. > > Also, although I'm volunteering to help, you should notice that the > > release team will have another PTL for Y, so, the lead of this topic is > > at the discretion of my replacant. > > > > I think a good starting point could be to design some specs or propose > > some related goals, so, Thomas, maybe you could start by creating > > something like that with your expectations. It will allow us to start > > this topic, share our different feedback and our expectations on it (our > > different viewpoints, at least from the release team, infra team, and > > downstream/distros teams). > > > > Hopefully it will help us. > > Hi Herve, > > Thanks a lot for your enthusiasm, volunteering, and all. > > I very much agree that it's too late for Xena, though I wasn't even > hoping for it that early. This was merely a suggestion. > > I will try to get my co-maintainer (Michal Arbet) in the loop so we can > at least design the blue-print together. I also have to give this some > thoughts myself before I can start. > > Cheers, > > Thomas Goirand (zigo) > > -- 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 arxcruz at redhat.com Wed Sep 8 12:10:52 2021 From: arxcruz at redhat.com (Arx Cruz) Date: Wed, 8 Sep 2021 14:10:52 +0200 Subject: [patrole][qa] Proposing Soniya Vyas to Patrole core In-Reply-To: References: <17bc1bcebec.d7cc6895149770.7494147722877953142@ghanshyammann.com> Message-ID: +1 Congratulations!!! On Wed, Sep 8, 2021 at 12:02 PM Chandan Kumar wrote: > On Wed, Sep 8, 2021 at 1:03 AM Ghanshyam Mann > wrote: > > > > ---- On Tue, 07 Sep 2021 14:15:04 -0500 Martin Kopec > wrote ---- > > > Hi all, > > > > > > Soniya Vyas (IRC: soniya29) is very enthusiastic about Patrole > project and since she has been very helpful, I'd like to propose her for > Patrole core. > > > > > > You can vote/feedback on this email. If no objections within a week, > I'll add her to the core list. > > > > +1, she has been very helpful in Patrole project. > > +1, Thank you Sonia for all the great work. > > Thanks, > > Chandan Kumar > > > -- Arx Cruz Software Engineer Red Hat EMEA arxcruz at redhat.com @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 8 12:46:11 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 8 Sep 2021 09:46:11 -0300 Subject: [cinder] Bug deputy report for week of 2021-08-09 Message-ID: This is a bug report from 2021-01-09 to 2021-08-09. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/1942696 "RateLimitingMiddleware still belongs to v2 API code" Medium - https://bugs.launchpad.net/cinder/+bug/1942953 "Upload volume to image will terminate the vm's volume attachment". Assigned to xuanyandong - https://bugs.launchpad.net/cinder/+bug/1942342 "Huawei FC driver fails to create a volume from a snapshot with Dorado V6 - Bad or unexpected response from the storage volume backend API: Create luncopy error". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1934036 "Undefined CONF.quota_metadata_items is used in unit tests". Assigned to Takashi Kajinami. 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 patryk.jakuszew at gmail.com Wed Sep 8 12:48:50 2021 From: patryk.jakuszew at gmail.com (Patryk Jakuszew) Date: Wed, 8 Sep 2021 14:48:50 +0200 Subject: [neutron] Slow router provisioning during full resync of L3 Agent Message-ID: Hello, I have a long-standing issue with L3 Agent which I would like to finally solve - *very* slow router provisioning in L3 Agent. We are operating a Rocky-based OpenStack deployment with three bare-metal L3 Agent nodes running in legacy mode. After restarting the L3 node, it takes a really long time for the L3 agent to become fully operational. There are two parts of resync which take much time: getting a list of routers from neutron-server and actually recreate them in the L3 node. While the long running time of router list retrieval is somewhat understandable, the router provisioning process itself proves to be very troublesome in our operations tasks. In our production deployment with around 250 routers, it takes around 2 hours (!) to recreate the router namespaces and have the L3 node fully functional again. Two hours of router re-provisioning is actually an optimistic scenario, this proved to be much longer during the outages we encountered (sometimes the sync took nearly 6-8 hours). This effectively prolongs any maintenance upgrades, configuration changes and OpenStack release upgrades. Another thing is, on that same production environment the first 100 routers usually get provisioned fast (around 30 minutes), after that it slows down with each router - this kind of non deterministic behavior makes it hard to communicate the maintenance finish ETA for our users. We also have a test environment with Stein already installed, where this problem is also present - full resync of 150 routers, with only one external gateway ports, takes around an hour to complete. Are there any operators here who also encountered that issue? Does anyone have any experience with similar situation and are willing to share their observations and optimizations? -- Regards, Patryk Jakuszew From fungi at yuggoth.org Wed Sep 8 13:14:09 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 8 Sep 2021 13:14:09 +0000 Subject: [all] Dangerous trend toward too many release-independent components In-Reply-To: <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> References: <20210907133947.wmosbwxdjkh6cren@yuggoth.org> <20210907232144.n25ei2cyrmkr2xaz@yuggoth.org> <1aaf9274-f669-1e7b-f2f2-4cf795f60f0c@debian.org> Message-ID: <20210908131409.273rtnfdw57rhweo@yuggoth.org> On 2021-09-08 10:27:50 +0200 (+0200), Thomas Goirand wrote: [...] > Ok, so your recommendation is that, for each and every component that is > marked release-independent, I should be checking the global > requirements. I just wrote that this is unrealistic that a human does > such a check. I'm not saying that a human needs to check it, in fact that file is machine-readable (it's used as input to pip but it's quite trivial to parse). What I said is that it's what we have now, and probably the closest thing we have to what you're asking for. It's a list of what exact versions of dependencies we test the software with, nothing more. We effectively freeze and branch that list whenever a new coordinated release of OpenStack happens, and then only adjust it to reflect stable point releases of our cycle-based deliverables. Any independent release deliverables in there are still basically frozen, treated just like any other "external" dependency of OpenStack. If it helps, we also maintain a redirector service which routes URLs like https://releases.openstack.org/constraints/upper/wallaby to a raw download of the correct file. We also make sure the codename for the cycle currently in progress is supported, so that you can begin using it in preparation for the next coordinated release. > If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack > with me together in Debian) wrote this: [...] > Thanks to this page, anyone can know the status of OpenStack packaging > on all the different branches we maintain. If you look at it right now, > you'll notice that we're up-to-date, as we packaged all non-clients and > all clients library, but we didn't package new versions of the puppet > manifests yet (I'm waiting for the RCs to do that). That's very cool! > If you click on the buster-victoria button, and look for Taskflow, > you'll see that it's up-to-date. If you click on bullseye-xena, and > search for Taskflow, you will ... find nothing! That's because taskflow > doesn't appear in https://releases.openstack.org/xena/index.html since > it is release-independent. As a result, I'm left with no other choice > than being very careful and manually check the global-requirements. [...] wget -qO- https://releases.openstack.org/constraints/upper/wallaby \ | grep -i ^taskflow= wget -qO- https://releases.openstack.org/constraints/upper/xena \ | grep -i ^taskflow= Its not ideal, no, but it's fairly straightforward (not that I would do it in shell script, but parsing that with the re module in Python's stdlib is trivial, or you could use something like the packaging.requirements parser from python3-packaging). As an aside, parsing HTML is very fiddly, you might consider directly consuming the structured data maintained in the openstack/releases repository as it's far easier to script (it's YAML). I believe the openstack_releases Python package even provides modules for parsing those. -- 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 tonykarera at gmail.com Wed Sep 8 13:16:57 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 8 Sep 2021 15:16:57 +0200 Subject: Tenant vlan Network Issue In-Reply-To: <5528888.crQR7OUkfV@p1> References: <5528888.crQR7OUkfV@p1> Message-ID: Hello Slawek, I really need your help. I have tried all I can but still the k8s-cluster gets stuck with this log here root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd /var/log/heat-config/heat-config-script/ [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7-kube_cluster_config-asfqq352zosg.log c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7-kube_masters-waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7-kube_cluster_config-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7-kube_cluster_config-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7-kube_cluster_config-asfqq352zosg.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 = '' ']' + sleep 5 ++ kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? + '[' ok = '' ']' + sleep 5 Regards Tony Karera On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski wrote: > 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 -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Sep 8 13:31:18 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 08 Sep 2021 15:31:18 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> Message-ID: <3773315.Oo1np0eLaN@p1> Hi, On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: > Hello Slawek, > > I really need your help. > > I have tried all I can but still the k8s-cluster gets stuck with this log > here > > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd > /var/log/heat-config/heat-config-script/ > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- kube_cluster_c > onfig-asfqq352zosg.log > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- kube_masters- > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- kube_cluster_c > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 > heat-config-script]# cat > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- kube_cluster_c > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 > heat-config-script]# cat > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- kube_cluster_c > onfig-asfqq352zosg.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 = '' ']' > + sleep 5 > ++ kubectl get --raw=/healthz > The connection to the server localhost:8080 was refused - did you specify > the right host or port? But why Your script is trying to connect to localhost? It's not the VM address I guess :) > + '[' ok = '' ']' > + sleep 5 > > > Regards > > Tony Karera > > > > > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski > > wrote: > > 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 -- 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 radoslaw.piliszek at gmail.com Wed Sep 8 13:44:29 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 8 Sep 2021 15:44:29 +0200 Subject: [all][tc] Minium python version for yoga and centos 9 stream. In-Reply-To: <50423dee4b245d18befa21bd7ef1666653f7bf2e.camel@redhat.com> References: <33913002aa0ad4be63f6c36be310f4e1dd7bd008.camel@redhat.com> <4b261268e701d3c464f180e89a795841c06dc8d0.camel@redhat.com> <17bc0e8dea4.fc87ca61142047.29866411617360676@ghanshyammann.com> <20210907160308.5qcih7675nbjwghu@yuggoth.org> <17bc125274c.114f9c117145230.1407351724601243402@ghanshyammann.com> <50423dee4b245d18befa21bd7ef1666653f7bf2e.camel@redhat.com> Message-ID: Sorry for top posting but I don't have a precise quote to reply to. What I wish to say is that I am trying to get Debian tested in CI but it looks like python3.9 might be playing tricks. I would appreciate it if someone more knowledgeable in Nova and Neutron internals could take a look at failures in https://review.opendev.org/c/openstack/devstack/+/789083 Do note slightly different tests fail each run. -yoctozepto On Tue, Sep 7, 2021 at 7:40 PM Sean Mooney wrote: > > On Tue, 2021-09-07 at 11:44 -0500, Ghanshyam Mann wrote: > > ---- On Tue, 07 Sep 2021 11:03:09 -0500 Jeremy Stanley wrote ---- > > > On 2021-09-07 10:38:12 -0500 (-0500), Ghanshyam Mann wrote: > > > [...] > > > > Definitely we can move to 3.9 as official testing runtime if any > > > > of the currently supporting distro support it as default. > > > [...] > > > > > > I don't think it needs to be the default Python in a release so long > > > as it's available. To quote from > > > https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests > > > > > > "Prior to the beginning of each release cycle, the TC will > > > designate the minor versions of Python 3 that will be tested in > > > that release using the following criteria: > > > [...] > > > The latest released version of Python 3 that is available in any > > > distribution we can feasibly use for testing. It need not be a > > > long-term-supported release, but could be a non-LTS version of > > > Ubuntu, Fedora, openSUSE Leap, or even a rolling release > > > distribution (such as Debian Testing or openSUSE Tumbleweed) if > > > necessary." > > > > > > I recall clearly that this was added so that we would attempt to > > > test the latest available version of Python in order to help avoid > > > having software which is clearly non-functional on distributions > > > which are working in parallel to update their defaults (and so might > > > reasonably want to ship OpenStack with an interpreter version which > > > was not their default at the time we started development for that > > > coordinated release). > > > > Sure, and by seeing the current py39 job it is mostly passing > > - https://zuul.openstack.org/builds?job_name=openstack-tox-py39 > > > > Let's discuss it in PTG and hopefully by then we might see centos9 > > release or closure plan to release dates and as discussed during > > defining the Yoga tetsing runtime, we can update it once if > > centos9 is there then update centos versionb as well as the py version > > otherwise we can disucss only making py39 jobs voting which are running > > on ubuntu focal. > not sure if centos 9 will be avaiable by ptg but i hope so. > in anycaes ubuntu 21.04 default to python 3.9 and debian 11 "bullseye" which is the latest > __stable__ debian release also default to python 3.9 as does fedora 34 but that a much bigger moving target. > > in general 3.9 is avaiable if not default in several distro which is why i would like to include it for > required testing e.g. move the current non voting jobs to voting for unit and functest at least. > it woudl be nice if we could have at least on tempst job on py39 too but sure lets pick this up at the ptg. > > im not agaisnt keeping support for phython 3.6 and centos 8 stream for yoga but i would like to be abel to > do at least some smoke tests with centos 9 stream if its avaiable. > > the none stream version fo centos 8 i think is end of life at the end of this year? but the centos 8 stream > release will continue untile rhel 8 is eol so that shoudl still be supproted to some degree for the full yoga cycle. > the none stream version however wont be supported when yoga releases. > > > > > > -gmann > > > > > -- > > > Jeremy Stanley > > > > > > > > From micou12 at gmail.com Wed Sep 8 09:49:03 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Wed, 8 Sep 2021 11:49:03 +0200 Subject: [ceph-users] Re: Replacing swift with RGW In-Reply-To: <20210906144401.Horde.7j4UyxpB4wl0f5RgwX1Y0FD@webmail.nde.ag> References: <20210901122221.Horde.v0FeoCUfex4WYSaXReGzV1i@webmail.nde.ag> <20210901134023.Horde.ZhZ0JBty-nYNsBfGe6WOijH@webmail.nde.ag> <20210902071439.Horde.4cayqDV75oyYS75eyQZMSPD@webmail.nde.ag> <20210902081741.Horde.Xp06qPUkci05sKXFlo1F5ap@webmail.nde.ag> <20210902083925.Horde.a0LD9j43RkGPIl7UuWCRtyu@webmail.nde.ag> <20210906144401.Horde.7j4UyxpB4wl0f5RgwX1Y0FD@webmail.nde.ag> Message-ID: Hello team, Now I am able to create containers and upload objects in the openstack CLI side using the following commands: (kolla-open1) stack at kolla-open1:~$ swift -V 1.0 -A http://ceph-mon2:8080/auth/v1 -U operator:swift -K opswift post my-container3 (kolla-open1) stack at kolla-open1:~$ swift -V 1.0 -A http://ceph-mon2:8080/auth/v1 -U operator:swift -K opswift upload my-container3 michel.txt above commands are successful and containers and their objects are stored in ceph RGW default pool which replace swift . The issues I remain with is that once I try to access the object store on horizon and click on containers it immediately disconnect hoizon to the login status. [image: image.png] [image: image.png] Kindly help and advise Michel On Mon, Sep 6, 2021 at 4:50 PM Eugen Block wrote: > It's hard to tell what is wrong with your setup, I don't really use > mine but this was the last working config I had to be able to create > swift containers directly in RGW: > > ---snip--- > # ceph.conf: > > [client.rgw.ses6-mon1] > rgw frontends = "beast port=80" > rgw dns name = ses6-mon1.example.com > rgw enable usage log = true > > rgw thread pool size = 512 > rgw keystone api version = 3 > rgw keystone url = http://control-node.example.com:5000 > > rgw keystone admin user = rgw > rgw keystone admin password = **** > rgw keystone admin domain = default > rgw keystone admin project = service > rgw keystone accepted roles = admin,Member,_member_,member > rgw keystone verify ssl = false > rgw s3 auth use keystone = true > rgw keystone revocation interval = 0 > > > # User role (I don't think admin is required) > > openstack role add --user rgw --project 9e8a67da237a4b26afb2819d2dea2219 > admin > > > # Create keystone endpoints > > openstack endpoint create --region RegionOne swift admin > "http://ses6-mon1.example.com:80/swift/v1" > openstack endpoint create --region RegionOne swift internal > "http://ses6-mon1.example.com:80/swift/v1" > openstack endpoint create --region RegionOne swift public > "http://ses6-mon1.example.com:80/swift/v1" > > > # Create container and files > > openstack container create swift1 > +---------+-----------+---------------------------------------------------+ > | account | container | x-trans-id | > +---------+-----------+---------------------------------------------------+ > | v1 | swift1 | tx000000000000000000001-0060b4ba48-d724dc-default | > +---------+-----------+---------------------------------------------------+ > > openstack object create --name file1 swift1 chef-client.log > +--------+-----------+----------------------------------+ > | object | container | etag | > +--------+-----------+----------------------------------+ > | file1 | swift1 | 56a1ed3b201c1e753bcbe80c640349f7 | > +--------+-----------+----------------------------------+ > ---snip--- > > > You are mixing dns names and IP addresses, I can't tell if that's a > problem but it probably should work, I'm not sure. Compared to my > ceph.conf these are the major differences: > > rgw keystone verify ssl = false > rgw s3 auth use keystone = true > rgw keystone revocation interval = 0 > > And I don't use rgw_keystone_token_cache_size. Maybe try again with > the options I use. > > > Zitat von Michel Niyoyita : > > > Hello, > > > > I am trying to replace swift by RGW as backend storage but I failed once > I > > try to post a container in the OpenStack side however, all interfaces are > > configured (admin, public and internal). but Once I post from RGW host it > > is created . Another issue is that object storage does not appear on the > > horizon dashboard . I have deployed openstack all-in-one using > > kolla-ansible and Os is ubuntu > > > > (kolla-open1) stack at kolla-open1:~$ swift -v post myswift > > Container POST failed: http://ceph-osd3:8080/swift/v1/myswift 401 > > Unauthorized b'AccessDenied' > > Failed Transaction ID: tx000000000000000000008-006135dcbd-87d63-default > > > > (kolla-open1) stack at kolla-open1:~$ swift list > > Account GET failed: http://ceph-osd3:8080/swift/v1?format=json 401 > > Unauthorized [first 60 chars of response] > > b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000c-' > > Failed Transaction ID: tx00000000000000000000c-006135de42-87d63-default > > > > Kindly help to solve the issue > > > > Michel > > > > On Thu, Sep 2, 2021 at 4:28 PM Alex Schultz wrote: > > > >> The swift docs are a bit out of date as they still reference python2 > >> despite python3 being supported for some time now. Replace python- with > >> python3- and try again. > >> > >> > >> On Thu, Sep 2, 2021 at 7:35 AM Michel Niyoyita > wrote: > >> > >>> > >>> > >>> ---------- Forwarded message --------- > >>> From: Michel Niyoyita > >>> Date: Thu, Sep 2, 2021 at 12:17 PM > >>> Subject: Fwd: [ceph-users] Re: Replacing swift with RGW > >>> To: > >>> > >>> > >>> > >>> > >>> ---------- Forwarded message --------- > >>> From: Eugen Block > >>> Date: Thu, Sep 2, 2021 at 10:39 AM > >>> Subject: Re: [ceph-users] Re: Replacing swift with RGW > >>> To: Michel Niyoyita > >>> > >>> > >>> You should continue this thread on the openstack-discuss mailing list > >>> (openstack-discuss at lists.openstack.org) since this is not a ceph > issue. > >>> I'm not familiar with kolla and I don't know the requirements to > >>> install openstack-swift, you'll need to ask the openstack community. > >>> > >>> > >>> Zitat von Michel Niyoyita : > >>> > >>> > Below are errors I am getting once I try to run swift commands . the > >>> second > >>> > one is the error I get once try to install python-swiftclient > >>> > > >>> > (kolla-open) [stack at kolla-open ~]$ swift -v stat > >>> > -bash: swift: command not found > >>> > (kolla-open) [stack at kolla-open ~]$ sudo yum -y install > >>> python-swiftclient > >>> > Last metadata expiration check: 0:59:21 ago on Thu 02 Sep 2021 > 09:21:53 > >>> AM > >>> > CAT. > >>> > No match for argument: python-swiftclient > >>> > Error: Unable to find a match: python-swiftclient > >>> > (kolla-open) [stack at kolla-open ~]$ > >>> > > >>> > Waiting for your help > >>> > > >>> > On Thu, Sep 2, 2021 at 10:17 AM Eugen Block wrote: > >>> > > >>> >> I can't tell for sure, but yes, I believe you need the > openstack-swift > >>> >> package (with dependencies). What errors do you get? The more > >>> >> information you share the better people can help. > >>> >> > >>> >> > >>> >> Zitat von Michel Niyoyita : > >>> >> > >>> >> > I tried to install "sudo yum -y install python-swiftclient" on > >>> openstack > >>> >> > side but fails . are there openastack-shwift packages which are > >>> needed? > >>> >> > if are there please help me to get . may be also it is the cause > I > >>> am > >>> >> > failing to run swift command on openstack cli side. > >>> >> > > >>> >> > thank you for your continued support. > >>> >> > > >>> >> > Micheal > >>> >> > > >>> >> > On Thu, Sep 2, 2021 at 9:14 AM Eugen Block wrote: > >>> >> > > >>> >> >> I only configured the endpoints for the clients to directly > access > >>> the > >>> >> >> RGWs, but you'll probably need to install the openstack-swift > >>> package. > >>> >> >> Or have you done that already? > >>> >> >> > >>> >> >> > >>> >> >> Zitat von Michel Niyoyita : > >>> >> >> > >>> >> >> > Thank you Eugen for your prompt response. > >>> >> >> > > >>> >> >> > Now the commands provided work. but I am not finding the object > >>> >> storage > >>> >> >> on > >>> >> >> > the horizon dashboard , but it appears in the system > information > >>> >> >> services. > >>> >> >> > [image: image.png] > >>> >> >> > so my question is how to configure it in order that it can > appear > >>> in > >>> >> the > >>> >> >> > dashboard . > >>> >> >> > > >>> >> >> > Michel > >>> >> >> > > >>> >> >> > On Wed, Sep 1, 2021 at 3:49 PM Eugen Block > wrote: > >>> >> >> > > >>> >> >> >> Sorry, one little detail slipped through, the '--region' flag > >>> has to > >>> >> >> >> be put before the 'service' name. The correct command would > be: > >>> >> >> >> > >>> >> >> >> openstack endpoint create --region RegionOne swift admin > >>> >> >> >> http://ceph-osd3:8080/swift/v1 > >>> >> >> >> > >>> >> >> >> and respectively for the other interfaces. > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> Zitat von Eugen Block : > >>> >> >> >> > >>> >> >> >> > Hi, > >>> >> >> >> > > >>> >> >> >> > this is not a ceph issue but your openstack cli command as > the > >>> >> error > >>> >> >> >> > message states. > >>> >> >> >> > > >>> >> >> >> > Try one interface at a time: > >>> >> >> >> > > >>> >> >> >> > openstack endpoint create swift public > >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift > >>> >> >> >> > openstack endpoint create swift admin > >>> >> http://ceph-osd3:8080/swift/v1 > >>> >> >> >> > --region RegionOne swift > >>> >> >> >> > openstack endpoint create swift internal > >>> >> >> >> > http://ceph-osd3:8080/swift/v1 --region RegionOne swift > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > Zitat von Michel Niyoyita : > >>> >> >> >> > > >>> >> >> >> >> Hello , > >>> >> >> >> >> > >>> >> >> >> >> Below are errors I am getting once I am trying to integrate > >>> swift > >>> >> >> with > >>> >> >> >> >> Radosgateway. > >>> >> >> >> >> > >>> >> >> >> >> From openstack side once i try to endpoint which will point > >>> to the > >>> >> >> >> >> radosgateway : > >>> >> >> >> >> > >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ openstack endpoint > >>> create > >>> >> >> >> >> --publicurl http://ceph-osd3:8080/swift/v1 --adminurl > >>> >> >> >> >> http://ceph-osd3:8080/swift/v1 --internal > >>> >> >> >> http://ceph-osd3:8080/swift/v1 > >>> >> >> >> >> --region RegionOne swift > >>> >> >> >> >> usage: openstack endpoint create [-h] [-f > >>> >> >> {json,shell,table,value,yaml}] > >>> >> >> >> >> [-c COLUMN] [--noindent] > >>> [--prefix > >>> >> >> >> PREFIX] > >>> >> >> >> >> [--max-width ] > >>> >> [--fit-width] > >>> >> >> >> >> [--print-empty] [--region > >>> >> >> ] > >>> >> >> >> >> [--enable | --disable] > >>> >> >> >> >> > >>> >> >> >> >> openstack endpoint create: error: argument : > >>> invalid > >>> >> >> choice: > >>> >> >> >> ' > >>> >> >> >> >> http://ceph-osd3:8080/swift/v1' (choose from 'admin', > >>> 'public', > >>> >> >> >> 'internal') > >>> >> >> >> >> > >>> >> >> >> >> (kolla-open) [stack at kolla-open kolla]$ > >>> >> >> >> >> > >>> >> >> >> >> below are my /etc/ceph/ceph.conf file : > >>> >> >> >> >> > >>> >> >> >> >> [client.rgw.ceph-osd3] > >>> >> >> >> >> rgw_dns_name = ceph-osd3 > >>> >> >> >> >> host = ceph-osd3 > >>> >> >> >> >> keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3/keyring > >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.log > >>> >> >> >> >> rgw frontends = civetweb port=10.10.29.110:8080 > >>> num_threads=100 > >>> >> >> >> >> rgw_keystone_url=http://10.10.29.150:35357 > >>> >> >> >> >> rgw_keystone_admin_user=admin > >>> >> >> >> >> rgw_keystone_admin_password=admin > >>> >> >> >> >> rgw_keystone_admin_tenant=admin > >>> >> >> >> >> rgw_keystone_accepted_role=admin Member swiftoperator > >>> >> >> >> >> rgw_keystone_token_cache_size=200 > >>> >> >> >> >> rgw_keystone_revocation_interval=300 > >>> >> >> >> >> > >>> >> >> >> >> [client.rgw.ceph-osd3.rgw0] > >>> >> >> >> >> host = ceph-osd3 > >>> >> >> >> >> keyring = > >>> /var/lib/ceph/radosgw/ceph-rgw.ceph-osd3.rgw0/keyring > >>> >> >> >> >> log file = /var/log/ceph/ceph-rgw-ceph-osd3.rgw0.log > >>> >> >> >> >> rgw frontends = beast endpoint=10.10.29.110:8080 > >>> >> >> >> >> rgw thread pool size = 512 > >>> >> >> >> >> > >>> >> >> >> >> please note that my rgw_dns_name = ceph_osd3 with > >>> 10.10.29.110 as > >>> >> IP > >>> >> >> >> >> > >>> >> >> >> >> and 10.10.29.150 all-in-one IP > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> Please crosscheck where I might make mistake and try to > >>> correct. > >>> >> >> >> >> > >>> >> >> >> >> Best regards > >>> >> >> >> >> > >>> >> >> >> >> Michel > >>> >> >> >> >> > >>> >> >> >> >> On Mon, Aug 30, 2021 at 11:25 AM Etienne Menguy < > >>> >> >> >> etienne.menguy at croit.io> > >>> >> >> >> >> wrote: > >>> >> >> >> >> > >>> >> >> >> >>> Hi, > >>> >> >> >> >>> > >>> >> >> >> >>> There are some information on Ceph documentation > >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/ < > >>> >> >> >> >>> https://docs.ceph.com/en/latest/radosgw/keystone/> . > >>> >> >> >> >>> - Use keystone as auth for RGW > >>> >> >> >> >>> - Create service and register your RGW as swift > >>> >> >> >> >>> > >>> >> >> >> >>> Étienne > >>> >> >> >> >>> > >>> >> >> >> >>>> On 27 Aug 2021, at 15:47, Michel Niyoyita < > >>> micou12 at gmail.com> > >>> >> >> wrote: > >>> >> >> >> >>>> > >>> >> >> >> >>>> Hello , > >>> >> >> >> >>>> > >>> >> >> >> >>>> I have configured RGW in my ceph cluster deployed using > ceph > >>> >> >> ansible > >>> >> >> >> and > >>> >> >> >> >>>> create sub user to access the created containers and > would > >>> like > >>> >> to > >>> >> >> >> >>> replace > >>> >> >> >> >>>> swift by RGW in the openstack side. Anyone can help on > >>> >> >> configuration > >>> >> >> >> to > >>> >> >> >> >>> be > >>> >> >> >> >>>> done in the OpenStack side in order to integrate those > >>> >> services. I > >>> >> >> >> have > >>> >> >> >> >>>> deployed OpenStack wallaby using Kolla-ansible on ubuntu > >>> 20.04. > >>> >> and > >>> >> >> >> ceph > >>> >> >> >> >>>> pacific 16.2.5 was deployed using ansible on ubuntu 20.04 > >>> >> >> >> >>>> > >>> >> >> >> >>>> Kindly help for the configuration or documentation. > >>> >> >> >> >>>> > >>> >> >> >> >>>> Best Regards > >>> >> >> >> >>>> > >>> >> >> >> >>>> Michel > >>> >> >> >> >>>> _______________________________________________ > >>> >> >> >> >>>> ceph-users mailing list -- ceph-users at ceph.io > >>> >> >> >> >>>> To unsubscribe send an email to ceph-users-leave at ceph.io > >>> >> >> >> >>> > >>> >> >> >> >>> _______________________________________________ > >>> >> >> >> >>> ceph-users mailing list -- ceph-users at ceph.io > >>> >> >> >> >>> To unsubscribe send an email to ceph-users-leave at ceph.io > >>> >> >> >> >>> > >>> >> >> >> >> _______________________________________________ > >>> >> >> >> >> ceph-users mailing list -- ceph-users at ceph.io > >>> >> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> _______________________________________________ > >>> >> >> >> ceph-users mailing list -- ceph-users at ceph.io > >>> >> >> >> To unsubscribe send an email to ceph-users-leave at ceph.io > >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> > >>> > >>> > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 11853 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 11591 bytes Desc: not available URL: From gmann at ghanshyammann.com Wed Sep 8 14:21:38 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 08 Sep 2021 09:21:38 -0500 Subject: [all][elections][ptl] Project Team Lead Election Conclusion and Results In-Reply-To: References: Message-ID: <17bc5c92365.1202dce8f194142.5550056093873382816@ghanshyammann.com> Thanks, Ian, Amy, Helena, Andy, and Belmiro for doing an awesome job as election officials and for the smooth running of both elections. -gmann ---- On Wed, 08 Sep 2021 06:56:50 -0500 Ian Y. Choi wrote ---- > Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. > > Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: > > * Barbican : Douglas Mendizábal > * Blazar : Pierre Riteau > * Cinder : Brian Rosmaita > * Cloudkitty : Rafael Weingartner > * Cyborg : Bailin Zhang > * Designate : Michael Johnson > * Ec2 Api : Andrey Pavlov > * Freezer : ge cong > * Glance : Abhishek Kekane > * Horizon : Vishal Manchanda > * Ironic : Iury Gregory Melo Ferreira > * Kolla : Michal Nasiadka > * Kuryr : Maysa de Macedo Souza > * Magnum : Feilong Wang > * Manila : Goutham Pacha Ravi > * Masakari : Radosław Piliszek > * Murano : Rong Zhu > * Neutron : Lajos Katona > * Nova : Sylvain Bauza > * Octavia : Gregory Thiemonge > * OpenStack Charms : Alex Kavanagh > * Openstack Chef : Lance Albertson > * OpenStack Helm : Gage Hugo > * OpenStackAnsible : Dmitriy Rabotyagov > * OpenStackSDK : Artem Goncharov > * Quality Assurance : Martin Kopec > * Rally : Andrey Kurilin > * Release Management : Elod Illes > * Requirements : Matthew Thode > * Senlin : XueFeng Liu > * Solum : Rong Zhu > * Storlets : Takashi Kajinami > * Swift : Tim Burke > * Tacker : Yasufumi Ogawa > * Telemetry : Matthias Runge > * Tripleo : James Slagle > * Trove : Lingxian Kong > * Vitrage : Eyal Bar-Ilan > * Watcher : chen ke > * Winstackers : Lucian Petrut > * Zaqar : wang hao > > Elections: > * Cyborg: https://civs1.civs.us/cgi-bin/results.pl?id=E_807146df7d6a1d3b > > Election process details and results are also available here: https://governance.openstack.org/election/ > > Thank you to all involved in the PTL election process, > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > From mkopec at redhat.com Wed Sep 8 14:24:08 2021 From: mkopec at redhat.com (Martin Kopec) Date: Wed, 8 Sep 2021 16:24:08 +0200 Subject: [designate][interop] test_create_all_recordset_types ddt issue Message-ID: Hi designate team, I'm reaching out because we have encountered a problem with one of the tests [1]. We track the following name [2]: designate_tempest_plugin.tests.api.v2.test_recordset.RecordsetsTest.test_create_all_recordset_types That test name is actually incorrect due to the ddt and the real name of the test is created dynamically based on the test data passed via ddt. We have a consistency check which is supposed to verify that the test names tracked in our guidelines match the ones in Tempest/tempest plugins, however, there was a bug - we are fixing that by [3]. The question is, should interop track all the permutations of the test? See [4]. [1] https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae2b39695ef6f03bbefb55afeacf1cdf3/designate_tempest_plugin/tests/api/v2/test_recordset.py#L87 [2] https://opendev.org/osf/interop/src/commit/d8eac71fa507c68e9c1f83a19dd77af8483d01b6/add-ons/guidelines/dns.2020.11.json#L116-L117 [3] https://review.opendev.org/c/osf/interop/+/806598 [4] https://review.opendev.org/c/osf/interop/+/807586 Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Wed Sep 8 15:24:57 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 8 Sep 2021 17:24:57 +0200 Subject: Tenant vlan Network Issue In-Reply-To: <3773315.Oo1np0eLaN@p1> References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Hello Slawek, Unfortunately I am not sure because all I did is configure the cluster. Nothing else. Regards Tony Karera On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski wrote: > Hi, > > On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: > > Hello Slawek, > > > > I really need your help. > > > > I have tried all I can but still the k8s-cluster gets stuck with this log > > here > > > > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd > > /var/log/heat-config/heat-config-script/ > > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls > > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- > kube_cluster_c > > onfig-asfqq352zosg.log > > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- > kube_masters- > > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log > > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat > > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- > kube_cluster_c > > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 > > heat-config-script]# cat > > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- > kube_cluster_c > > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 > > heat-config-script]# cat > > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- > kube_cluster_c > > onfig-asfqq352zosg.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 = '' ']' > > + sleep 5 > > ++ kubectl get --raw=/healthz > > The connection to the server localhost:8080 was refused - did you specify > > the right host or port? > > But why Your script is trying to connect to localhost? It's not the VM > address > I guess :) > > > + '[' ok = '' ']' > > + sleep 5 > > > > > > Regards > > > > Tony Karera > > > > > > > > > > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski > > > > wrote: > > > 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 > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Wed Sep 8 15:36:54 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 8 Sep 2021 20:36:54 +0500 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Hi karera, I don’t think your the error is related to network side. Its because kublet is not installed properly in your kubernetes master node. You need to check logs that why hyperkube services are not started. You can check it in heat logs on mater node and you can check the status of kubelet container via podman ps commad. Ammad On Wed, Sep 8, 2021 at 8:28 PM Karera Tony wrote: > Hello Slawek, > > Unfortunately I am not sure because all I did is configure the cluster. > Nothing else. > > > Regards > > Tony Karera > > > > > On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski > wrote: > >> Hi, >> >> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >> > Hello Slawek, >> > >> > I really need your help. >> > >> > I have tried all I can but still the k8s-cluster gets stuck with this >> log >> > here >> > >> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >> > /var/log/heat-config/heat-config-script/ >> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >> kube_cluster_c >> > onfig-asfqq352zosg.log >> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >> kube_masters- >> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >> kube_cluster_c >> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >> > heat-config-script]# cat >> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >> kube_cluster_c >> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >> > heat-config-script]# cat >> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >> kube_cluster_c >> > onfig-asfqq352zosg.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 = '' ']' >> > + sleep 5 >> > ++ kubectl get --raw=/healthz >> > The connection to the server localhost:8080 was refused - did you >> specify >> > the right host or port? >> >> But why Your script is trying to connect to localhost? It's not the VM >> address >> I guess :) >> >> > + '[' ok = '' ']' >> > + sleep 5 >> > >> > >> > Regards >> > >> > Tony Karera >> > >> > >> > >> > >> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski >> > >> > wrote: >> > > 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 >> >> >> -- >> Slawek Kaplonski >> Principal Software Engineer >> Red Hat > > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Wed Sep 8 15:48:30 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 8 Sep 2021 08:48:30 -0700 Subject: [designate][interop] test_create_all_recordset_types ddt issue In-Reply-To: References: Message-ID: Hi Martin, This is a really good question, thanks for bringing it up. Normally I would not include "ddt" tests in the interop test suite. I have two reasons for that opinion: 1. All DDT tests will end up with the same idempotent_id (UUID for the test), which makes them hard to track. 2. The list of tests generated from that "ddt" data will change over time as we add new recordset types [1]. We will also need to be very careful that the dataset order does not change. That said, those are important tests for the functionality of the Designate service. Users will expect to be able to create records of those types if they are using a "OpenStack Powered Platform with DNS" cloud. So, yes, I think we should keep them. I would expect the list to expand over time, with [1] being a candidate for that in the near future. If the use of "ddt" is a big problem for the compliance testing, we can consider breaking these out into individual tests (likely to be duplicates to the existing "ddt" tests to maintain the legacy test UUIDs). Michael [1] https://review.opendev.org/c/openstack/designate/+/802190 On Wed, Sep 8, 2021 at 7:28 AM Martin Kopec wrote: > > Hi designate team, > > I'm reaching out because we have encountered a problem with one of the tests [1]. We track the following name [2]: > designate_tempest_plugin.tests.api.v2.test_recordset.RecordsetsTest.test_create_all_recordset_types > > That test name is actually incorrect due to the ddt and the real name of the test is created dynamically based on the test data passed via ddt. > > We have a consistency check which is supposed to verify that the test names tracked in our guidelines match the ones in Tempest/tempest plugins, however, there was a bug - we are fixing that by [3]. > > The question is, should interop track all the permutations of the test? See [4]. > > [1] https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae2b39695ef6f03bbefb55afeacf1cdf3/designate_tempest_plugin/tests/api/v2/test_recordset.py#L87 > [2] https://opendev.org/osf/interop/src/commit/d8eac71fa507c68e9c1f83a19dd77af8483d01b6/add-ons/guidelines/dns.2020.11.json#L116-L117 > [3] https://review.opendev.org/c/osf/interop/+/806598 > [4] https://review.opendev.org/c/osf/interop/+/807586 > > Thank you, > -- > Martin Kopec > Senior Software Quality Engineer > Red Hat EMEA > > > From rosmaita.fossdev at gmail.com Wed Sep 8 16:00:17 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 8 Sep 2021 12:00:17 -0400 Subject: [ops][cinder] is anyone using RateLimitingMiddleware ? Message-ID: Hello operators, Takashi Kajinami noticed that cinder's RateLimitingMiddleware class lives among the legacy v2 classes and should be moved to live with the v3 classes, but then it occurred to him that maybe it should simply be deprecated and removed [0]. There are a few reasons to believe that nobody is actually using this functionality, for example, it's not included in the default api-paste.ini file, this middleware no longer exists in Nova, it gives you inexact behavior with multiple API nodes, etc. We discussed this topic at today's cinder meeting and decided to ask whether anyone is using the RateLimitingMiddleware with cinder before deprecating it for removal. If it's going to be deprecated, we'd like to do it in Xena, so please reply to this email or leave a comment on the deprecation patch [1] (or preferably both) before 23:59 UTC on Tuesday 14 September 2021. Thank you! [0] https://bugs.launchpad.net/cinder/+bug/1942696 [1] https://review.opendev.org/c/openstack/cinder/+/807469 From wodel.youchi at gmail.com Wed Sep 8 16:13:30 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 8 Sep 2021 17:13:30 +0100 Subject: Instances cannot ping each other and cannot ping virtual-router Message-ID: Hi, I deployed OpenStack Train using TripleO using this tutorial : https://kdjlab.com/deploying-rdo-in-a-cohesive-manner/ and the documentation of TripleO. I deployed it with DVR. In my deployment I am using virtual machines with nested-kvm. The deployment went well, I am using network isolation like this : - nic1 : provisioning - nic2 and nic3 (bond0) storage and storage mgmt networks, each one in it's VLAN - nic3 and nic5 (bond1) tenant, api and *external* (10.0.2.0/24 VLAN2100) networks, each one in it's VLAN In my physical host (the bare metal KVM) I created a bridge which handles the provisioning, tenant, api and external networks. I created a private tenant network (172.16.100.0/24). openstack network create private neutron subnet-create private 172.16.100.0/24 --name private-sub --dns-nameserver 172.16.0.252 I created a public network and I attached it to the external network using the same VLAN tag (10.0.2.0/24 VLAN 2100, pool: 10.0.2.100-10.0.2.120) : *openstack network create --provider-network-type vlan --provider-physical-network datacentre --provider-segment 2100 --external public* neutron subnet-create public 10.0.2.0/24 --name public-sub --disable-dhcp --allocation-pool=start=10.0.2.100,end=10.0.2.120 --gateway=10.0.2.1 --dns-nameserver 172.16.0.252 I created a vrouter, one port in the public network and the other in the private network. I created two cirrus instances, each one got it's ip address from the private network. I found : cirrus-1 : 172.16.100.81 cirrus-2 : 172.16.100.103 vrouter : 172.16.100.1 private : 10.0.2.101 external neutron:dhcp : 172.16.100.2 The problems : - The instances cannot ping each other. - The instances cannot ping the vrouter. - I cannot ping the public vrouter interface. But both instances can ping neutron:dhcp Could someone help me dig into this. Thanks in advance, Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltoscano at redhat.com Wed Sep 8 16:15:18 2021 From: ltoscano at redhat.com (Luigi Toscano) Date: Wed, 08 Sep 2021 18:15:18 +0200 Subject: [designate][interop] test_create_all_recordset_types ddt issue In-Reply-To: References: Message-ID: <3229108.usfYGdeWWP@whitebase.usersys.redhat.com> On Wednesday, 8 September 2021 17:48:30 CEST Michael Johnson wrote: > If the use of "ddt" is a big problem for the compliance testing, we > can consider breaking these out into individual tests (likely to be > duplicates to the existing "ddt" tests to maintain the legacy test > UUIDs). I was wondering: wouldn't it be possible to expand or use ddt somehow to inject different UUIDs for each generated test? You know in advance how many tests are going to be generated. -- Luigi From syedammad83 at gmail.com Wed Sep 8 16:20:53 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 8 Sep 2021 21:20:53 +0500 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: You can see here that kubelet container is not started. You need to check kubelet logs. Can you confirm which fcos version you are using? Ammad On Wed, Sep 8, 2021 at 9:17 PM Karera Tony wrote: > Hello Team, > > I tried to create another cluster with tls enabled and below are the > results for podman ps . I have also attached the heat logs > > podman ps > CONTAINER ID IMAGE > COMMAND CREATED STATUS PORTS > NAMES > e9c028723166 > docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 > /usr/bin/start-he... 34 minutes ago Up 34 minutes ago > heat-container-agent > 4128a9e951de k8s.gcr.io/hyperkube:v1.18.16 > kube-apiserver --... 30 minutes ago Up 30 minutes ago > kube-apiserver > 5430aa72e7f0 k8s.gcr.io/hyperkube:v1.18.16 > kube-controller-m... 30 minutes ago Up 30 minutes ago > kube-controller-manager > 8f2c76272916 k8s.gcr.io/hyperkube:v1.18.16 > kube-scheduler --... 30 minutes ago Up 30 minutes ago > kube-scheduler > af5f1a661c65 quay.io/coreos/etcd:v3.4.6 > /usr/local/bin/et... 30 minutes ago Up 30 minutes ago > etcd > > Regards > > Tony Karera > > > > > On Wed, Sep 8, 2021 at 5:37 PM Ammad Syed wrote: > >> Hi karera, >> >> I don’t think your the error is related to network side. Its because >> kublet is not installed properly in your kubernetes master node. You need >> to check logs that why hyperkube services are not started. >> >> You can check it in heat logs on mater node and you can check the status >> of kubelet container via podman ps commad. >> >> Ammad >> On Wed, Sep 8, 2021 at 8:28 PM Karera Tony wrote: >> >>> Hello Slawek, >>> >>> Unfortunately I am not sure because all I did is configure the cluster. >>> Nothing else. >>> >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski >>> wrote: >>> >>>> Hi, >>>> >>>> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >>>> > Hello Slawek, >>>> > >>>> > I really need your help. >>>> > >>>> > I have tried all I can but still the k8s-cluster gets stuck with this >>>> log >>>> > here >>>> > >>>> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >>>> > /var/log/heat-config/heat-config-script/ >>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>> kube_cluster_c >>>> > onfig-asfqq352zosg.log >>>> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >>>> kube_masters- >>>> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>> kube_cluster_c >>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>> > heat-config-script]# cat >>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>> kube_cluster_c >>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>> > heat-config-script]# cat >>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>> kube_cluster_c >>>> > onfig-asfqq352zosg.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 = '' ']' >>>> > + sleep 5 >>>> > ++ kubectl get --raw=/healthz >>>> > The connection to the server localhost:8080 was refused - did you >>>> specify >>>> > the right host or port? >>>> >>>> But why Your script is trying to connect to localhost? It's not the VM >>>> address >>>> I guess :) >>>> >>>> > + '[' ok = '' ']' >>>> > + sleep 5 >>>> > >>>> > >>>> > Regards >>>> > >>>> > Tony Karera >>>> > >>>> > >>>> > >>>> > >>>> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski >>> > >>>> > >>>> > wrote: >>>> > > 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 < >>>> tonykarera at gmail.com> >>>> > > >>>> > > 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 >>>> >>>> >>>> -- >>>> Slawek Kaplonski >>>> Principal Software Engineer >>>> Red Hat >>> >>> -- >> Regards, >> >> >> Syed Ammad Ali >> > -- Regards, Syed Ammad Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Wed Sep 8 16:33:07 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 8 Sep 2021 18:33:07 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Hello Ammad, Yes I can see. I cant see the kubelet logs. Please advise on how to check the fcos Logs. It is new to me unfortunately. Regards Tony Karera On Wed, Sep 8, 2021 at 6:21 PM Ammad Syed wrote: > You can see here that kubelet container is not started. You need to check > kubelet logs. > > Can you confirm which fcos version you are using? > > Ammad > On Wed, Sep 8, 2021 at 9:17 PM Karera Tony wrote: > >> Hello Team, >> >> I tried to create another cluster with tls enabled and below are the >> results for podman ps . I have also attached the heat logs >> >> podman ps >> CONTAINER ID IMAGE >> COMMAND CREATED STATUS PORTS >> NAMES >> e9c028723166 >> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 >> /usr/bin/start-he... 34 minutes ago Up 34 minutes ago >> heat-container-agent >> 4128a9e951de k8s.gcr.io/hyperkube:v1.18.16 >> kube-apiserver --... 30 minutes ago Up 30 minutes ago >> kube-apiserver >> 5430aa72e7f0 k8s.gcr.io/hyperkube:v1.18.16 >> kube-controller-m... 30 minutes ago Up 30 minutes ago >> kube-controller-manager >> 8f2c76272916 k8s.gcr.io/hyperkube:v1.18.16 >> kube-scheduler --... 30 minutes ago Up 30 minutes ago >> kube-scheduler >> af5f1a661c65 quay.io/coreos/etcd:v3.4.6 >> /usr/local/bin/et... 30 minutes ago Up 30 minutes ago >> etcd >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Sep 8, 2021 at 5:37 PM Ammad Syed wrote: >> >>> Hi karera, >>> >>> I don’t think your the error is related to network side. Its because >>> kublet is not installed properly in your kubernetes master node. You need >>> to check logs that why hyperkube services are not started. >>> >>> You can check it in heat logs on mater node and you can check the status >>> of kubelet container via podman ps commad. >>> >>> Ammad >>> On Wed, Sep 8, 2021 at 8:28 PM Karera Tony wrote: >>> >>>> Hello Slawek, >>>> >>>> Unfortunately I am not sure because all I did is configure the cluster. >>>> Nothing else. >>>> >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >>>>> > Hello Slawek, >>>>> > >>>>> > I really need your help. >>>>> > >>>>> > I have tried all I can but still the k8s-cluster gets stuck with >>>>> this log >>>>> > here >>>>> > >>>>> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >>>>> > /var/log/heat-config/heat-config-script/ >>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>> kube_cluster_c >>>>> > onfig-asfqq352zosg.log >>>>> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >>>>> kube_masters- >>>>> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>> kube_cluster_c >>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>> > heat-config-script]# cat >>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>> kube_cluster_c >>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>> > heat-config-script]# cat >>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>> kube_cluster_c >>>>> > onfig-asfqq352zosg.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 = '' ']' >>>>> > + sleep 5 >>>>> > ++ kubectl get --raw=/healthz >>>>> > The connection to the server localhost:8080 was refused - did you >>>>> specify >>>>> > the right host or port? >>>>> >>>>> But why Your script is trying to connect to localhost? It's not the VM >>>>> address >>>>> I guess :) >>>>> >>>>> > + '[' ok = '' ']' >>>>> > + sleep 5 >>>>> > >>>>> > >>>>> > Regards >>>>> > >>>>> > Tony Karera >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski < >>>>> skaplons at redhat.com> >>>>> > >>>>> > wrote: >>>>> > > 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 < >>>>> tonykarera at gmail.com> >>>>> > > >>>>> > > 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 >>>>> >>>>> >>>>> -- >>>>> Slawek Kaplonski >>>>> Principal Software Engineer >>>>> Red Hat >>>> >>>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Wed Sep 8 16:59:44 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 8 Sep 2021 21:59:44 +0500 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Can you confirm fedora coreOS version image you are using for magnum clusters ? I suspect you are using 34. Which have trouble with kubelet service. You should use version 33 or 32. You can check systemctl status kubelet service and its logs. On Wed, Sep 8, 2021 at 9:33 PM Karera Tony wrote: > Hello Ammad, > > Yes I can see. > > I cant see the kubelet logs. Please advise on how to check the fcos Logs. > > It is new to me unfortunately. > > Regards > > Tony Karera > > > > > On Wed, Sep 8, 2021 at 6:21 PM Ammad Syed wrote: > >> You can see here that kubelet container is not started. You need to check >> kubelet logs. >> >> Can you confirm which fcos version you are using? >> >> Ammad >> On Wed, Sep 8, 2021 at 9:17 PM Karera Tony wrote: >> >>> Hello Team, >>> >>> I tried to create another cluster with tls enabled and below are the >>> results for podman ps . I have also attached the heat logs >>> >>> podman ps >>> CONTAINER ID IMAGE >>> COMMAND CREATED STATUS PORTS >>> NAMES >>> e9c028723166 >>> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 >>> /usr/bin/start-he... 34 minutes ago Up 34 minutes ago >>> heat-container-agent >>> 4128a9e951de k8s.gcr.io/hyperkube:v1.18.16 >>> kube-apiserver --... 30 minutes ago Up 30 minutes ago >>> kube-apiserver >>> 5430aa72e7f0 k8s.gcr.io/hyperkube:v1.18.16 >>> kube-controller-m... 30 minutes ago Up 30 minutes ago >>> kube-controller-manager >>> 8f2c76272916 k8s.gcr.io/hyperkube:v1.18.16 >>> kube-scheduler --... 30 minutes ago Up 30 minutes ago >>> kube-scheduler >>> af5f1a661c65 quay.io/coreos/etcd:v3.4.6 >>> /usr/local/bin/et... 30 minutes ago Up 30 minutes ago >>> etcd >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Wed, Sep 8, 2021 at 5:37 PM Ammad Syed wrote: >>> >>>> Hi karera, >>>> >>>> I don’t think your the error is related to network side. Its because >>>> kublet is not installed properly in your kubernetes master node. You need >>>> to check logs that why hyperkube services are not started. >>>> >>>> You can check it in heat logs on mater node and you can check the >>>> status of kubelet container via podman ps commad. >>>> >>>> Ammad >>>> On Wed, Sep 8, 2021 at 8:28 PM Karera Tony >>>> wrote: >>>> >>>>> Hello Slawek, >>>>> >>>>> Unfortunately I am not sure because all I did is configure the >>>>> cluster. Nothing else. >>>>> >>>>> >>>>> Regards >>>>> >>>>> Tony Karera >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >>>>>> > Hello Slawek, >>>>>> > >>>>>> > I really need your help. >>>>>> > >>>>>> > I have tried all I can but still the k8s-cluster gets stuck with >>>>>> this log >>>>>> > here >>>>>> > >>>>>> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >>>>>> > /var/log/heat-config/heat-config-script/ >>>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>> kube_cluster_c >>>>>> > onfig-asfqq352zosg.log >>>>>> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >>>>>> kube_masters- >>>>>> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >>>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>> kube_cluster_c >>>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>>> > heat-config-script]# cat >>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>> kube_cluster_c >>>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>>> > heat-config-script]# cat >>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>> kube_cluster_c >>>>>> > onfig-asfqq352zosg.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 = '' ']' >>>>>> > + sleep 5 >>>>>> > ++ kubectl get --raw=/healthz >>>>>> > The connection to the server localhost:8080 was refused - did you >>>>>> specify >>>>>> > the right host or port? >>>>>> >>>>>> But why Your script is trying to connect to localhost? It's not the >>>>>> VM address >>>>>> I guess :) >>>>>> >>>>>> > + '[' ok = '' ']' >>>>>> > + sleep 5 >>>>>> > >>>>>> > >>>>>> > Regards >>>>>> > >>>>>> > Tony Karera >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski < >>>>>> skaplons at redhat.com> >>>>>> > >>>>>> > wrote: >>>>>> > > 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 < >>>>>> tonykarera at gmail.com> >>>>>> > > >>>>>> > > 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 >>>>>> >>>>>> >>>>>> -- >>>>>> Slawek Kaplonski >>>>>> Principal Software Engineer >>>>>> Red Hat >>>>> >>>>> -- >>>> 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 Wed Sep 8 16:17:42 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 8 Sep 2021 18:17:42 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Hello Team, I tried to create another cluster with tls enabled and below are the results for podman ps . I have also attached the heat logs podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e9c028723166 docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 /usr/bin/start-he... 34 minutes ago Up 34 minutes ago heat-container-agent 4128a9e951de k8s.gcr.io/hyperkube:v1.18.16 kube-apiserver --... 30 minutes ago Up 30 minutes ago kube-apiserver 5430aa72e7f0 k8s.gcr.io/hyperkube:v1.18.16 kube-controller-m... 30 minutes ago Up 30 minutes ago kube-controller-manager 8f2c76272916 k8s.gcr.io/hyperkube:v1.18.16 kube-scheduler --... 30 minutes ago Up 30 minutes ago kube-scheduler af5f1a661c65 quay.io/coreos/etcd:v3.4.6 /usr/local/bin/et... 30 minutes ago Up 30 minutes ago etcd Regards Tony Karera On Wed, Sep 8, 2021 at 5:37 PM Ammad Syed wrote: > Hi karera, > > I don’t think your the error is related to network side. Its because > kublet is not installed properly in your kubernetes master node. You need > to check logs that why hyperkube services are not started. > > You can check it in heat logs on mater node and you can check the status > of kubelet container via podman ps commad. > > Ammad > On Wed, Sep 8, 2021 at 8:28 PM Karera Tony wrote: > >> Hello Slawek, >> >> Unfortunately I am not sure because all I did is configure the cluster. >> Nothing else. >> >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski >> wrote: >> >>> Hi, >>> >>> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >>> > Hello Slawek, >>> > >>> > I really need your help. >>> > >>> > I have tried all I can but still the k8s-cluster gets stuck with this >>> log >>> > here >>> > >>> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >>> > /var/log/heat-config/heat-config-script/ >>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>> kube_cluster_c >>> > onfig-asfqq352zosg.log >>> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >>> kube_masters- >>> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>> kube_cluster_c >>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>> > heat-config-script]# cat >>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>> kube_cluster_c >>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>> > heat-config-script]# cat >>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>> kube_cluster_c >>> > onfig-asfqq352zosg.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 = '' ']' >>> > + sleep 5 >>> > ++ kubectl get --raw=/healthz >>> > The connection to the server localhost:8080 was refused - did you >>> specify >>> > the right host or port? >>> >>> But why Your script is trying to connect to localhost? It's not the VM >>> address >>> I guess :) >>> >>> > + '[' ok = '' ']' >>> > + sleep 5 >>> > >>> > >>> > Regards >>> > >>> > Tony Karera >>> > >>> > >>> > >>> > >>> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski >>> > >>> > wrote: >>> > > 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 < >>> tonykarera at gmail.com> >>> > > >>> > > 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 >>> >>> >>> -- >>> Slawek Kaplonski >>> Principal Software Engineer >>> Red Hat >> >> -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 965d744e-2a63-4aec-9a65-ab83c92a47b4-k8s-cluster1-vnfx5pwx57gt-kube_masters-ikh4or2pa3o6-0-vawscctajrms-master_config-dchrxrgxwlou.log Type: application/octet-stream Size: 238556 bytes Desc: not available URL: From james.slagle at gmail.com Wed Sep 8 18:07:18 2021 From: james.slagle at gmail.com (James Slagle) Date: Wed, 8 Sep 2021 14:07:18 -0400 Subject: [TripleO] Yoga PTG topics etherpad Message-ID: I've started an etherpad where we can collect topics for discussion at the upcoming PTG: https://etherpad.opendev.org/p/tripleo-yoga-topics Please add topics over the next couple of weeks, and then we'll work on a schedule. Thanks. -- -- James Slagle -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From adivya1.singh at gmail.com Wed Sep 8 18:31:36 2021 From: adivya1.singh at gmail.com (Adivya Singh) Date: Thu, 9 Sep 2021 00:01:36 +0530 Subject: Steps for Controller Node Removal in Victoria Version Openstack using ansible Message-ID: Hello Team, Is there any way , We can have a link or guide to decommission a controller node We have 3 controller nodes and 4 compute nodes, and we are planning to Scale down the Infrastructure by 1 controller and 2 compute nodes Regards Adivya Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Wed Sep 8 18:37:28 2021 From: tonykarera at gmail.com (Karera Tony) Date: Wed, 8 Sep 2021 20:37:28 +0200 Subject: Tenant vlan Network Issue In-Reply-To: References: <5528888.crQR7OUkfV@p1> <3773315.Oo1np0eLaN@p1> Message-ID: Hello Ammad, Thanks a lot Bro. I will really really appreciate it. The issue was on the Fedore-coreos I was using. I changed to 33 and everything worked OK. Thanks a lot everyone. Regards Regards Tony Karera On Wed, Sep 8, 2021 at 6:59 PM Ammad Syed wrote: > Can you confirm fedora coreOS version image you are using for magnum > clusters ? > > I suspect you are using 34. Which have trouble with kubelet service. You > should use version 33 or 32. > > You can check systemctl status kubelet service and its logs. > > On Wed, Sep 8, 2021 at 9:33 PM Karera Tony wrote: > >> Hello Ammad, >> >> Yes I can see. >> >> I cant see the kubelet logs. Please advise on how to check the fcos Logs. >> >> It is new to me unfortunately. >> >> Regards >> >> Tony Karera >> >> >> >> >> On Wed, Sep 8, 2021 at 6:21 PM Ammad Syed wrote: >> >>> You can see here that kubelet container is not started. You need to >>> check kubelet logs. >>> >>> Can you confirm which fcos version you are using? >>> >>> Ammad >>> On Wed, Sep 8, 2021 at 9:17 PM Karera Tony wrote: >>> >>>> Hello Team, >>>> >>>> I tried to create another cluster with tls enabled and below are the >>>> results for podman ps . I have also attached the heat logs >>>> >>>> podman ps >>>> CONTAINER ID IMAGE >>>> COMMAND CREATED STATUS PORTS >>>> NAMES >>>> e9c028723166 >>>> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1 >>>> /usr/bin/start-he... 34 minutes ago Up 34 minutes ago >>>> heat-container-agent >>>> 4128a9e951de k8s.gcr.io/hyperkube:v1.18.16 >>>> kube-apiserver --... 30 minutes ago Up 30 minutes ago >>>> kube-apiserver >>>> 5430aa72e7f0 k8s.gcr.io/hyperkube:v1.18.16 >>>> kube-controller-m... 30 minutes ago Up 30 minutes ago >>>> kube-controller-manager >>>> 8f2c76272916 k8s.gcr.io/hyperkube:v1.18.16 >>>> kube-scheduler --... 30 minutes ago Up 30 minutes ago >>>> kube-scheduler >>>> af5f1a661c65 quay.io/coreos/etcd:v3.4.6 >>>> /usr/local/bin/et... 30 minutes ago Up 30 minutes ago >>>> etcd >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> >>>> >>>> On Wed, Sep 8, 2021 at 5:37 PM Ammad Syed >>>> wrote: >>>> >>>>> Hi karera, >>>>> >>>>> I don’t think your the error is related to network side. Its because >>>>> kublet is not installed properly in your kubernetes master node. You need >>>>> to check logs that why hyperkube services are not started. >>>>> >>>>> You can check it in heat logs on mater node and you can check the >>>>> status of kubelet container via podman ps commad. >>>>> >>>>> Ammad >>>>> On Wed, Sep 8, 2021 at 8:28 PM Karera Tony >>>>> wrote: >>>>> >>>>>> Hello Slawek, >>>>>> >>>>>> Unfortunately I am not sure because all I did is configure the >>>>>> cluster. Nothing else. >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Tony Karera >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Sep 8, 2021 at 3:31 PM Slawek Kaplonski >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On środa, 8 września 2021 15:16:57 CEST Karera Tony wrote: >>>>>>> > Hello Slawek, >>>>>>> > >>>>>>> > I really need your help. >>>>>>> > >>>>>>> > I have tried all I can but still the k8s-cluster gets stuck with >>>>>>> this log >>>>>>> > here >>>>>>> > >>>>>>> > root at k8s-cluster-1-vo5s5jvtjoa7-master-0 core]# cd >>>>>>> > /var/log/heat-config/heat-config-script/ >>>>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# ls >>>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>>> kube_cluster_c >>>>>>> > onfig-asfqq352zosg.log >>>>>>> > c42dcbf1-7812-49a2-b312-96c24225b407-k8s-cluster-1-vo5s5jvtjoa7- >>>>>>> kube_masters- >>>>>>> > waugw6vksw5p-0-vrt2gkfugedg-master_config-xv3vlmr27r46.log >>>>>>> > [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 heat-config-script]# cat >>>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>>> kube_cluster_c >>>>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>>>> > heat-config-script]# cat >>>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>>> kube_cluster_c >>>>>>> > onfig-asfqq352zosg.log [root at k8s-cluster-1-vo5s5jvtjoa7-master-0 >>>>>>> > heat-config-script]# cat >>>>>>> > a70c65af-34e2-4071-be18-2e4d66f85cf6-k8s-cluster-1-vo5s5jvtjoa7- >>>>>>> kube_cluster_c >>>>>>> > onfig-asfqq352zosg.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 = '' ']' >>>>>>> > + sleep 5 >>>>>>> > ++ kubectl get --raw=/healthz >>>>>>> > The connection to the server localhost:8080 was refused - did you >>>>>>> specify >>>>>>> > the right host or port? >>>>>>> >>>>>>> But why Your script is trying to connect to localhost? It's not the >>>>>>> VM address >>>>>>> I guess :) >>>>>>> >>>>>>> > + '[' ok = '' ']' >>>>>>> > + sleep 5 >>>>>>> > >>>>>>> > >>>>>>> > Regards >>>>>>> > >>>>>>> > Tony Karera >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Mon, Aug 30, 2021 at 8:50 AM Slawek Kaplonski < >>>>>>> skaplons at redhat.com> >>>>>>> > >>>>>>> > wrote: >>>>>>> > > 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, < >>>>>>> mnaser at vexxhost.com> wrote: >>>>>>> > > > > Your issue is that tenant_network_types should be vxlan. >>>>>>> > > > > >>>>>>> > > > > On Sat, Aug 28, 2021 at 4:29 AM Karera Tony < >>>>>>> tonykarera at gmail.com> >>>>>>> > > >>>>>>> > > 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 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Slawek Kaplonski >>>>>>> Principal Software Engineer >>>>>>> Red Hat >>>>>> >>>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> Syed Ammad Ali >>>>> >>>> -- >>> Regards, >>> >>> >>> Syed Ammad Ali >>> >> -- > Regards, > > > Syed Ammad Ali > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haleyb.dev at gmail.com Wed Sep 8 19:10:55 2021 From: haleyb.dev at gmail.com (Brian Haley) Date: Wed, 8 Sep 2021 15:10:55 -0400 Subject: [neutron] Slow router provisioning during full resync of L3 Agent In-Reply-To: References: Message-ID: Hi Patryk, Yes, the re-synchronization of the l3-agent can sometimes be time consuming. A number of things have been added over the years to help speed this up, some are in Rocky, some are in later releases. On 9/8/21 8:48 AM, Patryk Jakuszew wrote: > Hello, > > I have a long-standing issue with L3 Agent which I would like to > finally solve - *very* slow router provisioning in L3 Agent. > > We are operating a Rocky-based OpenStack deployment with three > bare-metal L3 Agent nodes running in legacy mode. After restarting the > L3 node, it takes a really long time for the L3 agent to become fully > operational. There are two parts of resync which take much time: > getting a list of routers from neutron-server and actually recreate > them in the L3 node. The first of these, getting info from neutron-server, was initially fixed in 2015 and has been enhanced over the years - retrieving routers in 'chunks' to reduce the load on neutron-server, since trying to get info on 250 routers is a large response to construct. When this happens do you see neutron-server under heavy load? It might be you need to tune the number of RPC workers in this instance to help. The second has also been slowly improved on the l3-agent side in a number of ways, for example, by dynamically increasing worker threads when long backlogs occur (not in Rocky). Other changes like using privsep instead of rootwrap has brought the times down slightly as well. There are probably others I'm not thinking of... > While the long running time of router list retrieval is somewhat > understandable, the router provisioning process itself proves to be > very troublesome in our operations tasks. In our production deployment > with around 250 routers, it takes around 2 hours (!) to recreate the > router namespaces and have the L3 node fully functional again. Two > hours of router re-provisioning is actually an optimistic scenario, > this proved to be much longer during the outages we encountered > (sometimes the sync took nearly 6-8 hours). This effectively prolongs > any maintenance upgrades, configuration changes and OpenStack release > upgrades. > > Another thing is, on that same production environment the first 100 > routers usually get provisioned fast (around 30 minutes), after that > it slows down with each router - this kind of non deterministic > behavior makes it hard to communicate the maintenance finish ETA for > our users. > > We also have a test environment with Stein already installed, where > this problem is also present - full resync of 150 routers, with only > one external gateway ports, takes around an hour to complete. > > Are there any operators here who also encountered that issue? Does > anyone have any experience with similar situation and are willing to > share their observations and optimizations? Yes, I know of other operators that have encountered this issue, and the community has tried to address it over the years. It seems you might have some of the fixes, but not all of them, and some tuning of worker threads might help. That said, I've never seen sync times in the 6-8 hour range, I wonder if the systems in question are under any CPU or memory pressure? Are there any other failures in the logs that show things timing out, like RPC failure/retries? Some other thoughts: Last year (2020) there were a number of debug messages added to the l3-agent that might help pinpoint where time is being spent for each router being processed, but that will not be in either of the later releases you mentioned. Maybe if you could install your test environment with something much newer it would help resolve or debug the issue better? Using the OVN mechanism driver totally eliminates the l3-agent, but I believe you'd need to jump to Victoria (?) in order to use that. -Brian From patryk.jakuszew at gmail.com Wed Sep 8 21:34:46 2021 From: patryk.jakuszew at gmail.com (Patryk Jakuszew) Date: Wed, 8 Sep 2021 23:34:46 +0200 Subject: [neutron] Slow router provisioning during full resync of L3 Agent In-Reply-To: References: Message-ID: Hi Brian, On Wed, 8 Sept 2021 at 21:10, Brian Haley wrote: > The first of these, getting info from neutron-server, was initially > fixed in 2015 and has been enhanced over the years - retrieving routers > in 'chunks' to reduce the load on neutron-server, since trying to get > info on 250 routers is a large response to construct. When this happens > do you see neutron-server under heavy load? It might be you need to > tune the number of RPC workers in this instance to help. > > The second has also been slowly improved on the l3-agent side in a > number of ways, for example, by dynamically increasing worker threads > when long backlogs occur (not in Rocky). Other changes like using > privsep instead of rootwrap has brought the times down slightly as well. > There are probably others I'm not thinking of... In our test environment I noticed that indeed there was a higher CPU load on neutron-server. I will take a look at both of the options that you mentioned - recently I've seen some mentions of adjusting RPC workers to CPU count in order to improve inter-service communication, but I didn't know about the possibility of switching between privsep and rootwrap. > That said, I've never seen sync times in the 6-8 hour range, I wonder if > the systems in question are under any CPU or memory pressure? Are there > any other failures in the logs that show things timing out, like RPC > failure/retries? This indeed happened during a full resync caused by a major outage of the entire RabbitMQ cluster. (Upgrade from 3.6.x to 3.9.x went wrong) Our control plane runs mostly on VMs, with exception of Neutron services which run on dedicated physical nodes. During the upgrade we actually wanted to add more vCPUs to RabbitMQ machines, but after noticing the control plane instability we rolled back that change. I will conduct more tests to see how much load is generated during the resync. > Some other thoughts: > > Last year (2020) there were a number of debug messages added to the > l3-agent that might help pinpoint where time is being spent for each > router being processed, but that will not be in either of the later > releases you mentioned. Maybe if you could install your test > environment with something much newer it would help resolve or debug the > issue better? > > Using the OVN mechanism driver totally eliminates the l3-agent, but I > believe you'd need to jump to Victoria (?) in order to use that. > > -Brian If newer releases have much more debug information available, then it is definitely worth checking out - I tried gathering some initial information about duration of certain operations by attaching py-spy into neutron-l3-agent (https://github.com/benfred/py-spy), but it didn't actually say how long it took for particular operations to complete. As for OVN... I have evaluated it a bit on my private environment (packstack all-in-one) and while it does have many welcome improvements like the elimination of separate agent processes, it also misses a feature that makes it a no-go for our production environment - neutron-vpnaas support. We have *lots* of users that would not be happy if we took away neutron-vpnaas. :/ Thank you very much for all the information - now I have some additional directions to look at. -- Best regards, Patryk Jakuszew On Wed, 8 Sept 2021 at 21:10, Brian Haley wrote: > > Hi Patryk, > > Yes, the re-synchronization of the l3-agent can sometimes be time > consuming. A number of things have been added over the years to help > speed this up, some are in Rocky, some are in later releases. > > On 9/8/21 8:48 AM, Patryk Jakuszew wrote: > > Hello, > > > > I have a long-standing issue with L3 Agent which I would like to > > finally solve - *very* slow router provisioning in L3 Agent. > > > > We are operating a Rocky-based OpenStack deployment with three > > bare-metal L3 Agent nodes running in legacy mode. After restarting the > > L3 node, it takes a really long time for the L3 agent to become fully > > operational. There are two parts of resync which take much time: > > getting a list of routers from neutron-server and actually recreate > > them in the L3 node. > > The first of these, getting info from neutron-server, was initially > fixed in 2015 and has been enhanced over the years - retrieving routers > in 'chunks' to reduce the load on neutron-server, since trying to get > info on 250 routers is a large response to construct. When this happens > do you see neutron-server under heavy load? It might be you need to > tune the number of RPC workers in this instance to help. > > The second has also been slowly improved on the l3-agent side in a > number of ways, for example, by dynamically increasing worker threads > when long backlogs occur (not in Rocky). Other changes like using > privsep instead of rootwrap has brought the times down slightly as well. > There are probably others I'm not thinking of... > > > While the long running time of router list retrieval is somewhat > > understandable, the router provisioning process itself proves to be > > very troublesome in our operations tasks. In our production deployment > > with around 250 routers, it takes around 2 hours (!) to recreate the > > router namespaces and have the L3 node fully functional again. Two > > hours of router re-provisioning is actually an optimistic scenario, > > this proved to be much longer during the outages we encountered > > (sometimes the sync took nearly 6-8 hours). This effectively prolongs > > any maintenance upgrades, configuration changes and OpenStack release > > upgrades. > > > > Another thing is, on that same production environment the first 100 > > routers usually get provisioned fast (around 30 minutes), after that > > it slows down with each router - this kind of non deterministic > > behavior makes it hard to communicate the maintenance finish ETA for > > our users. > > > > We also have a test environment with Stein already installed, where > > this problem is also present - full resync of 150 routers, with only > > one external gateway ports, takes around an hour to complete. > > > > Are there any operators here who also encountered that issue? Does > > anyone have any experience with similar situation and are willing to > > share their observations and optimizations? > > Yes, I know of other operators that have encountered this issue, and the > community has tried to address it over the years. It seems you might > have some of the fixes, but not all of them, and some tuning of worker > threads might help. > > That said, I've never seen sync times in the 6-8 hour range, I wonder if > the systems in question are under any CPU or memory pressure? Are there > any other failures in the logs that show things timing out, like RPC > failure/retries? > > Some other thoughts: > > Last year (2020) there were a number of debug messages added to the > l3-agent that might help pinpoint where time is being spent for each > router being processed, but that will not be in either of the later > releases you mentioned. Maybe if you could install your test > environment with something much newer it would help resolve or debug the > issue better? > > Using the OVN mechanism driver totally eliminates the l3-agent, but I > believe you'd need to jump to Victoria (?) in order to use that. > > -Brian From os-user157 at protonmail.com Wed Sep 8 21:34:15 2021 From: os-user157 at protonmail.com (os-user157) Date: Wed, 08 Sep 2021 21:34:15 +0000 Subject: [devstack][openstack-qa] DevStack on VirtualBox with Host-only Adapter Message-ID: Hi all, I'm trying to deploy DevStack inside an Ubuntu Server 20.04.3 LTS virtual machine inside VirtualBox, but I'm struggling a lot, I got a lot of different errors. My use case: I want to test Zuul and DevStack, so I'll create a virtual machine for DevStack and one for Zuul, both on VirtualBox. I'm using a Host-only adapter with CIDR 192.168.200.0/24, and I need DevStack to be accessible on this network, and to use this network as the floating range for giving floating IP addresses to instances inside DevStack, so that Zuul can also access them. My local.conf: https://paste.openstack.org/show/809182/ Screenshots of the network configuration of my VirtualBox VM: First adapter, NAT (used for internet connectivity): https://i.imgur.com/C7XTiLJ.png Second adapter, host-only, used for communication with my Windows host and other VMs in the same network: https://i.imgur.com/Qeciuqx.png DevStack is erroring with the arping command on lib/neutron-legacy, arping gets 0 responses and exits the script with exit code 1 Does anyone have experience in dpeloying DevStack inside VirtualBox in such manner? I really need some help with this, if anyone could give me some ideas of waht could be wrong, it'd very much appreciated! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From os-user157 at protonmail.com Wed Sep 8 21:37:30 2021 From: os-user157 at protonmail.com (os-user157) Date: Wed, 08 Sep 2021 21:37:30 +0000 Subject: [devstack][openstack-qa] DevStack on VirtualBox with Host-only Adapter Message-ID: <1CDGGTuntimwQAUEHVBdZvwxrY5s1aYy2ccWSYtqPUl9JbKg4Y6cMBPv1TKCCDCPmNLQ6SWfZNe76BnDmpQUGWtfzZAEdtXJdz4fsCrn3Yo=@protonmail.com> Hi all, I'm trying to deploy DevStack inside an Ubuntu Server 20.04.3 LTS virtual machine inside VirtualBox, but I'm struggling a lot, I got a lot of different errors. My use case: I want to test Zuul and DevStack, so I'll create a virtual machine for DevStack and one for Zuul, both on VirtualBox. I'm using a Host-only adapter with CIDR 192.168.200.0/24, and I need DevStack to be accessible on this network, and to use this network as the floating range for giving floating IP addresses to instances inside DevStack, so that Zuul can also access them. My local.conf: https://paste.openstack.org/show/809182/ Screenshots of the network configuration of my VirtualBox VM: First adapter, NAT (used for internet connectivity): https://i.imgur.com/C7XTiLJ.png Second adapter, host-only, used for communication with my Windows host and other VMs in the same network: https://i.imgur.com/Qeciuqx.png DevStack is erroring with the arping command on lib/neutron-legacy, arping gets 0 responses and exits the script with exit code 1 Does anyone have experience in dpeloying DevStack inside VirtualBox in such manner? I really need some help with this, if anyone could give me some ideas of waht could be wrong, it'd very much appreciated! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Sep 8 23:01:28 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 08 Sep 2021 16:01:28 -0700 Subject: =?UTF-8?Q?Re:_[devstack][openstack-qa]_DevStack_on_VirtualBox_with_Host-?= =?UTF-8?Q?only_Adapter?= In-Reply-To: <1CDGGTuntimwQAUEHVBdZvwxrY5s1aYy2ccWSYtqPUl9JbKg4Y6cMBPv1TKCCDCPmNLQ6SWfZNe76BnDmpQUGWtfzZAEdtXJdz4fsCrn3Yo=@protonmail.com> References: <1CDGGTuntimwQAUEHVBdZvwxrY5s1aYy2ccWSYtqPUl9JbKg4Y6cMBPv1TKCCDCPmNLQ6SWfZNe76BnDmpQUGWtfzZAEdtXJdz4fsCrn3Yo=@protonmail.com> Message-ID: <05c67c42-4527-4031-b291-14bcaa0aa7e6@www.fastmail.com> On Wed, Sep 8, 2021, at 2:37 PM, os-user157 wrote: > Hi all, > > I'm trying to deploy DevStack inside an Ubuntu Server 20.04.3 LTS > virtual machine inside VirtualBox, but I'm struggling a lot, I got a > lot of different errors. > > My use case: I want to test Zuul and DevStack, so I'll create a virtual > machine for DevStack and one for Zuul, both on VirtualBox. I'm using a > Host-only adapter with CIDR 192.168.200.0/24, and I need DevStack to be > accessible on this network, and to use this network as the floating > range for giving floating IP addresses to instances inside DevStack, so > that Zuul can also access them. > > My local.conf: https://paste.openstack.org/show/809182/ > Screenshots of the network configuration of my VirtualBox VM: > First adapter, NAT (used for internet connectivity): > https://i.imgur.com/C7XTiLJ.png > Second adapter, host-only, used for communication with my Windows host > and other VMs in the same network: https://i.imgur.com/Qeciuqx.png > > DevStack is erroring with the arping command on lib/neutron-legacy, > arping gets 0 responses and exits the script with exit code 1 > > Does anyone have experience in dpeloying DevStack inside VirtualBox in > such manner? I really need some help with this, if anyone could give me > some ideas of waht could be wrong, it'd very much appreciated! Thanks. I've not done this before, but the multinode devstack + tempest CI jobs do something similar. In those jobs we create a layer2 network using vxlan between the instances then set up layer three such that 172.24.4.0/24 is used for the openstack services and 172.24.5.0/24 is used as the floating IP range. Then we have routes set up for 172.24.4.0/23 as on link connections allowing both /24 ranges to be routed properly. The disjoint sets are important here and I notice that you are overlapping your service/infrastructure IPs and the floating IP range. The first thing I would do is change that. Maybe use 192.168.200.128/25 as the floating IP range and then avoid that for the services. Also when you get errors from devstack it helps tremendously if you can share pastes of them so that others can see context and maybe understand why things broke. Another thing to note: running instances without nested virt is slow and may not produce a great Zuul test environment. When using nested virt we have noticed random crashes are relatively common. Something to be aware of. Are you trying to set this up for Zuul and Nodepool development? If so the Zuul and Nodepool test suites are actually pretty good at mocking out the cloud interactions and then upstream CI does do final verification against a devstack cloud. All that to say it might be easier to just rely on the test suite. Hope this helps, Clark From gmann at ghanshyammann.com Thu Sep 9 00:11:14 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 08 Sep 2021 19:11:14 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Sept 9th at 1500 UTC In-Reply-To: <17bbc2d846e.11adf55c390492.8839891819324332226@ghanshyammann.com> References: <17bbc2d846e.11adf55c390492.8839891819324332226@ghanshyammann.com> Message-ID: <17bc7e4eff5.1161f6233210248.5053739727733279750@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 Tracker ** https://etherpad.opendev.org/p/tc-xena-tracker * Leaderless projects ** https://etherpad.opendev.org/p/yoga-leaderless * New project application: 'Venus' ** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html ** https://review.opendev.org/c/openstack/governance/+/804824 * Next step on pain points from projects/SIGs/pop-up (ricolin) ** https://etherpad.opendev.org/p/pain-point-elimination * TC tags analysis ** https://docs.google.com/spreadsheets/d/18GXibtdQnSkIwA7DsBvX9dPwbw9JH76AhhRUknzBb3Q/edit * TC Video call feedback & plan: ** https://etherpad.opendev.org/p/tc-video-meeting-feedback * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 06 Sep 2021 12:35:04 -0500 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Sept 9th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Sept 8th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From skaplons at redhat.com Thu Sep 9 07:19:14 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 09 Sep 2021 09:19:14 +0200 Subject: [neutron] Slow router provisioning during full resync of L3 Agent In-Reply-To: References: Message-ID: <31788380.zD9AKE7zTE@p1> Hi, On środa, 8 września 2021 23:34:46 CEST Patryk Jakuszew wrote: > Hi Brian, > > On Wed, 8 Sept 2021 at 21:10, Brian Haley wrote: > > The first of these, getting info from neutron-server, was initially > > fixed in 2015 and has been enhanced over the years - retrieving routers > > in 'chunks' to reduce the load on neutron-server, since trying to get > > info on 250 routers is a large response to construct. When this happens > > do you see neutron-server under heavy load? It might be you need to > > tune the number of RPC workers in this instance to help. > > > > The second has also been slowly improved on the l3-agent side in a > > number of ways, for example, by dynamically increasing worker threads > > when long backlogs occur (not in Rocky). Other changes like using > > privsep instead of rootwrap has brought the times down slightly as well. > > > > There are probably others I'm not thinking of... > > In our test environment I noticed that indeed there was a higher CPU > load on neutron-server. I will take a look at both of the options that > you mentioned - recently I've seen some mentions of adjusting RPC > workers to CPU count in order to improve inter-service communication, > but I didn't know about the possibility of switching between privsep > and rootwrap. > > > That said, I've never seen sync times in the 6-8 hour range, I wonder if > > the systems in question are under any CPU or memory pressure? Are there > > any other failures in the logs that show things timing out, like RPC > > failure/retries? > > This indeed happened during a full resync caused by a major outage of > the entire RabbitMQ cluster. (Upgrade from 3.6.x to 3.9.x went wrong) > > Our control plane runs mostly on VMs, with exception of Neutron > services which run on dedicated physical nodes. During the upgrade we > actually wanted to add more vCPUs to RabbitMQ machines, but after > noticing the control plane instability we rolled back that change. I > will conduct more tests to see how much load is generated during the > resync. > > > Some other thoughts: > > > > Last year (2020) there were a number of debug messages added to the > > l3-agent that might help pinpoint where time is being spent for each > > router being processed, but that will not be in either of the later > > releases you mentioned. Maybe if you could install your test > > environment with something much newer it would help resolve or debug the > > issue better? > > > > Using the OVN mechanism driver totally eliminates the l3-agent, but I > > believe you'd need to jump to Victoria (?) in order to use that. > > > > -Brian > > If newer releases have much more debug information available, then it > is definitely worth checking out - I tried gathering some initial > information about duration of certain operations by attaching py-spy > into neutron-l3-agent (https://github.com/benfred/py-spy), but it > didn't actually say how long it took for particular operations to > complete. > > As for OVN... I have evaluated it a bit on my private environment > (packstack all-in-one) and while it does have many welcome > improvements like the elimination of separate agent processes, it also > misses a feature that makes it a no-go for our production environment > - neutron-vpnaas support. We have *lots* of users that would not be > happy if we took away neutron-vpnaas. :/ Support for vpnaas in OVN backend is already reported as RFE: https:// bugs.launchpad.net/neutron/+bug/1905391 - unfortunatelly that work stopped some time ago and there is no progress now. But maybe You would have time and want to help with it - any help is welcome :) > > Thank you very much for all the information - now I have some > additional directions to look at. > > -- > Best regards, > Patryk Jakuszew > > On Wed, 8 Sept 2021 at 21:10, Brian Haley wrote: > > Hi Patryk, > > > > Yes, the re-synchronization of the l3-agent can sometimes be time > > consuming. A number of things have been added over the years to help > > speed this up, some are in Rocky, some are in later releases. > > > > On 9/8/21 8:48 AM, Patryk Jakuszew wrote: > > > Hello, > > > > > > I have a long-standing issue with L3 Agent which I would like to > > > finally solve - *very* slow router provisioning in L3 Agent. > > > > > > We are operating a Rocky-based OpenStack deployment with three > > > bare-metal L3 Agent nodes running in legacy mode. After restarting the > > > L3 node, it takes a really long time for the L3 agent to become fully > > > operational. There are two parts of resync which take much time: > > > getting a list of routers from neutron-server and actually recreate > > > them in the L3 node. > > > > The first of these, getting info from neutron-server, was initially > > fixed in 2015 and has been enhanced over the years - retrieving routers > > in 'chunks' to reduce the load on neutron-server, since trying to get > > info on 250 routers is a large response to construct. When this happens > > do you see neutron-server under heavy load? It might be you need to > > tune the number of RPC workers in this instance to help. > > > > The second has also been slowly improved on the l3-agent side in a > > number of ways, for example, by dynamically increasing worker threads > > when long backlogs occur (not in Rocky). Other changes like using > > privsep instead of rootwrap has brought the times down slightly as well. > > > > There are probably others I'm not thinking of... > > > > > While the long running time of router list retrieval is somewhat > > > understandable, the router provisioning process itself proves to be > > > very troublesome in our operations tasks. In our production deployment > > > with around 250 routers, it takes around 2 hours (!) to recreate the > > > router namespaces and have the L3 node fully functional again. Two > > > hours of router re-provisioning is actually an optimistic scenario, > > > this proved to be much longer during the outages we encountered > > > (sometimes the sync took nearly 6-8 hours). This effectively prolongs > > > any maintenance upgrades, configuration changes and OpenStack release > > > upgrades. > > > > > > Another thing is, on that same production environment the first 100 > > > routers usually get provisioned fast (around 30 minutes), after that > > > it slows down with each router - this kind of non deterministic > > > behavior makes it hard to communicate the maintenance finish ETA for > > > our users. > > > > > > We also have a test environment with Stein already installed, where > > > this problem is also present - full resync of 150 routers, with only > > > one external gateway ports, takes around an hour to complete. > > > > > > Are there any operators here who also encountered that issue? Does > > > anyone have any experience with similar situation and are willing to > > > share their observations and optimizations? > > > > Yes, I know of other operators that have encountered this issue, and the > > community has tried to address it over the years. It seems you might > > have some of the fixes, but not all of them, and some tuning of worker > > threads might help. > > > > That said, I've never seen sync times in the 6-8 hour range, I wonder if > > the systems in question are under any CPU or memory pressure? Are there > > any other failures in the logs that show things timing out, like RPC > > failure/retries? > > > > Some other thoughts: > > > > Last year (2020) there were a number of debug messages added to the > > l3-agent that might help pinpoint where time is being spent for each > > router being processed, but that will not be in either of the later > > releases you mentioned. Maybe if you could install your test > > environment with something much newer it would help resolve or debug the > > issue better? > > > > Using the OVN mechanism driver totally eliminates the l3-agent, but I > > believe you'd need to jump to Victoria (?) in order to use that. > > > > -Brian -- 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 Sep 9 07:32:21 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 09 Sep 2021 09:32:21 +0200 Subject: [neutron][neutron-vpnaas] Propose to EOL stable/queens, stable/rocky and stable/stein branches or neutron-vpnaas Message-ID: <127605535.TiF7tupeXR@p1> Hi, On our last meeting of the CI team we discussed the problem with broken stable branches (stein and older) in the neutron-vpnaas project [1]. I checked that last patches which were merged in those branches are more than year ago: * Queens - last merged patch in April 2019 * Rocky - last merged patch in February 2020 * Stein - last merged patch in September 2019 Giving the above and the current status of the CI in those branches, I propose to make them End Of Life. I will wait until end of next week for anyone who would like to maybe step up as maintainer of those branches and who would at least try to fix CI of them. If there will be no volunteers for that, I will EOL those branches in neutron- vpnaas. [1] https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci. 2021-09-07-15.00.log.html#l-64 -- 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 zhang.lei.fly+os-discuss at gmail.com Thu Sep 9 07:47:57 2021 From: zhang.lei.fly+os-discuss at gmail.com (Jeffrey Zhang) Date: Thu, 9 Sep 2021 15:47:57 +0800 Subject: Question about vDPA support for live migration Message-ID: Hey everyone, I am testing vDPA on OpenStack Wallaby. I have set it up successfully. But I found there are several features that are not implemented, including live/code migration[0], which I wanted. Anyone know what's the latest progress about this. when will the live migration feature land? I found no talk about this. [0] https://review.opendev.org/c/openstack/nova/+/780866/3/ releasenotes/notes/vdpa-cc2300d2c46c150b.yaml Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Thu Sep 9 07:52:17 2021 From: mkopec at redhat.com (Martin Kopec) Date: Thu, 9 Sep 2021 09:52:17 +0200 Subject: [designate][interop] test_create_all_recordset_types ddt issue In-Reply-To: <3229108.usfYGdeWWP@whitebase.usersys.redhat.com> References: <3229108.usfYGdeWWP@whitebase.usersys.redhat.com> Message-ID: >From interop perspective it's also better not to have multiple tests with the same id. We encountered one more problem with ddt - the test names seem not to be generated consistently, see this: https://paste.opendev.org/show/809187/ The test can have either _00009_TXT suffix or _9_TXT one. Until we figure this out, I think we will need to flag the test in interop - so that a skip of the test (because of the name mismatch in this case) won't make the whole guideline fail. Luigi's idea is great. Every test should be identified by a unique id and it shouldn't matter that the test is generated (ddt). Different input data -> different test -> different name -> different id. Let's try to explore whether having a unique id per ddt entry is possible. On Wed, 8 Sept 2021 at 18:15, Luigi Toscano wrote: > On Wednesday, 8 September 2021 17:48:30 CEST Michael Johnson wrote: > > If the use of "ddt" is a big problem for the compliance testing, we > > can consider breaking these out into individual tests (likely to be > > duplicates to the existing "ddt" tests to maintain the legacy test > > UUIDs). > > I was wondering: wouldn't it be possible to expand or use ddt somehow to > inject different UUIDs for each generated test? You know in advance how > many > tests are going to be generated. > > -- > Luigi > > > -- Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From micou12 at gmail.com Thu Sep 9 08:10:27 2021 From: micou12 at gmail.com (Michel Niyoyita) Date: Thu, 9 Sep 2021 10:10:27 +0200 Subject: Horizon connection errors from object store Message-ID: Hello team , I am facing an issue when I am trying to connect to the object store containers on the horizon dashboad . Once click on containers it automatically disconnect. please find below logs I am getting and help for further analysis. [Thu Sep 09 06:35:22.185771 2021] [wsgi:error] [pid 167:tid 139887608641280] [remote 10.10.29.150:55130] Attempted scope to domain Default failed, will attempt to scope to another domain. [Thu Sep 09 06:35:22.572522 2021] [wsgi:error] [pid 167:tid 139887608641280] [remote 10.10.29.150:55130] Login successful for user "admin" using domain "Default", remote address 10.10.29.150. [Thu Sep 09 06:35:51.494815 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] REQ: curl -i http://ceph-mon2:8080/swift/v1?format=json&limit=1001 -X GET -H "X-Auth-Token: gAAAAABhOasqHFyB..." -H "Accept-Encoding: gzip" [Thu Sep 09 06:35:51.495140 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP STATUS: 401 Unauthorized [Thu Sep 09 06:35:51.495541 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP HEADERS: {'Content-Length': '119', 'X-Trans-Id': 'tx00000000000000000000f-006139ab44-9fc1a-default', 'X-Openstack-Request-Id': 'tx00000000000000000000f-006139ab44-9fc1a-default', 'Accept-Ranges': 'bytes', 'Content-Type': 'application/json; charset=utf-8', 'Date': 'Thu, 09 Sep 2021 06:35:51 GMT', 'Connection': 'Keep-Alive'} [Thu Sep 09 06:35:51.495792 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP BODY: b'{"Code":"AccessDenied","RequestId":"tx00000000000000000000f-006139ab44-9fc1a-default","HostId":"9fc1a-default-default"}' [Thu Sep 09 06:35:51.498743 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] Unauthorized: /api/swift/containers/ [Thu Sep 09 06:35:52.924169 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] REQ: curl -i http://ceph-mon2:8080/swift/v1?format=json&limit=1001 -X GET -H "X-Auth-Token: gAAAAABhOasqHFyB..." -H "Accept-Encoding: gzip" [Thu Sep 09 06:35:52.924520 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP STATUS: 401 Unauthorized [Thu Sep 09 06:35:52.924789 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP HEADERS: {'Content-Length': '119', 'X-Trans-Id': 'tx000000000000000000010-006139ab48-9fc1a-default', 'X-Openstack-Request-Id': 'tx000000000000000000010-006139ab48-9fc1a-default', 'Accept-Ranges': 'bytes', 'Content-Type': 'application/json; charset=utf-8', 'Date': 'Thu, 09 Sep 2021 06:35:52 GMT', 'Connection': 'Keep-Alive'} [Thu Sep 09 06:35:52.925034 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] RESP BODY: b'{"Code":"AccessDenied","RequestId":"tx000000000000000000010-006139ab48-9fc1a-default","HostId":"9fc1a-default-default"}' [Thu Sep 09 06:35:52.929398 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] Unauthorized: /api/swift/containers/ [Thu Sep 09 06:35:52.935799 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:56016] Logging out user "admin". [Thu Sep 09 06:35:53.061489 2021] [wsgi:error] [pid 166:tid 139887608641280] [remote 10.10.29.150:55806] Logging out user "". [Thu Sep 09 06:35:54.541593 2021] [wsgi:error] [pid 165:tid 139887608641280] [remote 10.10.29.150:55852] The request's session was deleted before the request completed. The user may have logged out in a concurrent request, for example. [Thu Sep 09 06:35:54.542896 2021] [wsgi:error] [pid 165:tid 139887608641280] [remote 10.10.29.150:55852] Bad Request: /api/swift/policies/ [Thu Sep 09 06:35:54.566055 2021] [wsgi:error] [pid 167:tid 139887608641280] [remote 10.10.29.150:55860] The request's session was deleted before the request completed. The user may have logged out in a concurrent request, for example. [Thu Sep 09 06:35:54.567130 2021] [wsgi:error] [pid 167:tid 139887608641280] [remote 10.10.29.150:55860] Bad Request: /api/swift/info/ (kolla-open1) stack at kolla-open1 :/var/lib/docker/volumes/kolla_logs/_data/horizon$ Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueha.ayumu at fujitsu.com Thu Sep 9 09:23:16 2021 From: ueha.ayumu at fujitsu.com (ueha.ayumu at fujitsu.com) Date: Thu, 9 Sep 2021 09:23:16 +0000 Subject: [heat] Issue happend during server_group creation with policies Message-ID: Hi heat team. I reported the following bug report [1] on Sep 2. [1] https://storyboard.openstack.org/#!/story/2009164 Have you confirmed it? This error seems to appear to have occurred after patch [2] was merged. [2] https://review.opendev.org/c/openstack/heat/+/783971 Please kindly check it, thanks. Regards, Ayumu Ueha -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Sep 9 10:11:06 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 09 Sep 2021 12:11:06 +0200 Subject: [neutron] Drivers meeting agenda - 10.09.2021 Message-ID: <4687421.kKWKmoin3I@p1> Hi, Agenda for our tomorrow's drivers meeting is at [1]. We have 3 RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1830014 - [RFE] add API for neutron debug tool "probe" - there is also spec proposed for that one [2] * https://bugs.launchpad.net/neutron/+bug/1916428 - dibbler tool for dhcpv6 is concluded * https://bugs.launchpad.net/neutron/+bug/1870319 - [RFE] Network cascade deletion API call All of them are pretty old but we need to get back to them and hopefully decide something :) See You all on the meeting tomorrow. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://review.opendev.org/c/openstack/neutron-specs/+/662541 -- 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 nikitakalyanov at gmail.com Thu Sep 9 10:43:52 2021 From: nikitakalyanov at gmail.com (Nikita Kalyanov) Date: Thu, 9 Sep 2021 13:43:52 +0300 Subject: [oslo] RFE requested for oslo-messaging Message-ID: Dear Release Team, We experienced strange freezes and timeouts for a long time on our OpenStack deployment [1] and some duplicate messages [2]. After applying the fixes [3], [4] both bugs are gone. Is a freeze exception possible for these? Thanks! nkalyanov [1] https://bugs.launchpad.net/oslo.messaging/+bug/1935864 [2] https://bugs.launchpad.net/oslo.messaging/+bug/1935883 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/800564 [4] https://review.opendev.org/c/openstack/oslo.messaging/+/800575 From radoslaw.piliszek at gmail.com Thu Sep 9 11:00:26 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 9 Sep 2021 13:00:26 +0200 Subject: [oslo] RFE requested for oslo-messaging In-Reply-To: References: Message-ID: On Thu, Sep 9, 2021 at 12:44 PM Nikita Kalyanov wrote: > > Dear Release Team, > > We experienced strange freezes and timeouts for a long time on our > OpenStack deployment [1] and some duplicate messages [2]. After > applying the fixes [3], [4] both bugs are gone. Hmm, I have read the bug reports out of curiosity and I think we might be hitting these issues randomly in Kolla CI (due to load or bad network). (I am obviously unsure whether the proposed fixes are correct or not.) As these are bugfixes, they should not need a freeze exception per se. I hope Oslo messaging cores respond soon. -yoctozepto > > Is a freeze exception possible for these? > > Thanks! > nkalyanov > > [1] https://bugs.launchpad.net/oslo.messaging/+bug/1935864 > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1935883 > [3] https://review.opendev.org/c/openstack/oslo.messaging/+/800564 > [4] https://review.opendev.org/c/openstack/oslo.messaging/+/800575 > From smooney at redhat.com Thu Sep 9 11:25:21 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 09 Sep 2021 12:25:21 +0100 Subject: Question about vDPA support for live migration In-Reply-To: References: Message-ID: <8e698e1a0adbaabe00db9732fc90f7eba167d22f.camel@redhat.com> On Thu, 2021-09-09 at 15:47 +0800, Jeffrey Zhang wrote: > Hey everyone, > > I am testing vDPA on OpenStack Wallaby. I have set it up successfully. But > I found there are several features that are not implemented, including > live/code migration[0], which I wanted. > > Anyone know what's the latest progress about this. when will the live > migration feature land? > I found no talk about this. high i had planned on anding some more feature in xena but i was not able to work on it this cycle live migration is not a feature we can enable currently as qemu does not support it so it will likely be the Z or A cycle before live migration will be supported. currently we really only support boot, start/stop/reboot (hard and soft)/rebuild and vm delete in termes of lifecycle events. i had hoped to add shelve, evacuate, resize and cold migration in xena but i will try to find time to work on it in yoga instead. resize to same host works but we blocked it sicne resize to different host was untested. shelve works but unshelve failed and i did not have time to understand why during wallaby suspend fails because i have not extended it to unplug the vdpa devices like pci devices and libvirt managed_save requires that. if resize to different host works cold migrate will too they go hand in hand. evacuate is just rebuild to adifferent host i suspect it will mostly work but like cold migrate it was untested and we will need to ensure the devices are claimed correctly. interface attach works but it blocked because qemu raised an error if we tried to detach im hopintg that