October 2020 - openstack-discuss - lists.openstack.org

[kolla] Wallaby PTG summary
by Mark Goddard 30 Oct '20

30 Oct '20

Hi, Thanks to everyone who joined the virtual PTG sessions this week. We had some great discussions covering many different topics. I will try to provide a summary here. # Victoria cycle retrospective The Ubuntu Focal migration went smoothly. Core reviewer bandwidth was hurt by the pandemic, but we did pick up towards the end of the cycle and landed a good number of features. As usual, lots of CI fires to extinguish. # Review Victoria PTG Actions We looked back at the actions from the last PTG. Quite a few are still incomplete - we should do a better job of reviewing these. We agreed that the docs-related actions are still the most important. Any help with improving our documentation is appreciated. # General topics ## Ability to run CI jobs locally (without Zuul, but possibly with Ansible) This depends on a Zuul feature called Zuul Runner [1], which should be ready soon. yoctozepto signed up to test it out and document how to use it with Kolla. ## Future of Kolla Klub and Kall The Kolla Klub started well, with lots of involvement, and some good sessions. Over time, attendance has fallen, and the agenda still seems to be largely driven by me. Keeping up productive sessions every two weeks is starting to feel like a bit of a chore, and I think we need to change things up or stop. We agreed to try rebooting at a time that better suits contributors in APAC, possibly recycling some earlier material. There was a proposal at the summit to have monthly ops meetups, and maybe we would do well to link these related communities. We had a few ideas for how to improve the productivity of the more development oriented Kolla Kall, including multiple smaller groups, pair/mob programming, and fewer longer sessions. ## Keep or drop lower-constraints jobs? We didn't find many reasons to keep the lower-constraints jobs, and they do seem to need a bit of maintenance. We voted 2 in favour to remove them, with everyone else not having strong feelings. ## How can we integrate better with our user & contributor base outside of EU/US timezones? Kolla has a large user base outside of EU/US timezones, but the core team and surrounding community is not always that effective at involving these users. We agreed to try to improve the situation by reaching out to known community members in other regions, and offering some limited mentorship. # Kolla ## Infra images This feature has been in progress for a few cycles, but is proving difficult to land. The main blocker now is in CI. We need to split our image build CI jobs into several pipelines. They need to share a local docker registry. This pattern should open up a few other interesting features. ## New Docker Hub limits Docker hub is changing its policy for anonymous and free users. This affects retention of unused images, and limits the number of pulls in a 6 hour period (100 for anonymous users, limited by IP, 200 for logged in free users). This is likely to affect users running without a local registry. Fl1nt agreed to add some information to our documentation to help users. This is likely also to impact our CI jobs, which need to pull images. There is an application process to be listed as an open source project, which we need to ask the opendev infra team to apply for. # Kolla Ansible ## More fine grained skipping of tasks, e.g. allow to skip service registration priteau proposed making it easier to skip certain tasks during deployment, such as bootstrapping or service registration. There are two obvious ways to do this - a new 'action' (e.g. deploy-without-register), or add tags to the relevant tasks, which may be skipped. A third approach is to combine two commands - genconfig & deploy-containers. This is related to work currently going to allow configuration to be generated separately from container deployment. In the end, we considered adding tags, as well as the two command approach. ## Deprecate reconfigure command? The reconfigure command is now essentially the same as deploy. This is a source of confusion for users, so we agreed to deprecate reconfigure. We will keep reconfigure as an alias for deploy at the CLI level. ## Modernise the old skool Swift role The Swift role is the last (except Bifrost, which is generally weird), to use the old format, prior to the better-reconfigure blueprint. This has some limitations, so we should bring it into line. Nothing controversial here, just needs someone to pick it up. ## DNS-based endpoint naming rafaelweingartne has proposed a mini spec [2] for DNS-based endpoint naming. I think we now have a reasonable idea of his solution (which is to use Consul for service discovery, and avoid HAProxy for internal API communication), however the hard part is defining the problem that is being solved. ## Support to identity federation (OpenID Connect) configurations in Keystone and Horizon via Kolla-ansible There is a patch [3] to support this which has been open for some time. It requires some fairly specific knowledge to review, and the challenge will be in making core reviewers confident that it works. We agreed that CI testing and/or documentation of a simple development environment would help. ## podman Podman keeps coming up as a replacement for Docker. There are several issues here, including support on Debian/Ubuntu - we do not want to maintain support for two container engines. We agreed that this is likely to be a large feature, and that we should get started with a proof of concept in Wallaby, possibly with a spec to tease out the details. Fl1nt may have some time early 2021 for this, but anyone is welcome to pick it up. ## Finish Masakari integration We don't have support for the host monitor, which is arguably the most useful part of Masakari. With yoctozepto as Masakari PTL, we expect to see good progress in Wallaby. ## Performance improvements We made some good progress with performance improvement in Victoria. There is always more that can be done, and the next phase will probably involve splitting roles that target both control and compute hosts. Mitogen [4] is also an interesting option. As always, changes should be based on benchmarks [5]. ## Let's Encrypt integration - container running certbot, triggers certificate distribution yoctozepto added initial support for the ACME protocol in Ussuri, and the next step is to support deployment of a certbot container, and unattended certificate rotation. There are lots of fiddly details here, including how to bootstrap it. headphoneJames offered to write up a high level description of how the pieces fit together. ## Support for HAProxy reload (e.g. for TLS) Currently any configuration changes to HAProxy require a restart to be applied. This causes connections to be dropped. We discussed adding support for hitless reloads of HAProxy [6]. ## Native fluentd logging We didn't discuss this as kevko was busy, but I thought I'd add it here anyway. The idea is to use use logging.conf to configure services for native fluentd logging. This avoids all the regexes in fluentd, but may change our document schema in Elasticsearch. Patch [7] is up for review. # Kayobe ## Support multiple environments from a single kayobe configuration This feature has been on the cards for some time, and is an important step for Kayobe. priteau has proposed a patch [8] which is a good starting point. We spent a good hour going over some of the outstanding issues, and made some good progress. We agreed on the need to keep the meaning of KAYOBE_CONFIG_PATH intact, and to allow a branch to define the default environment to use. We agreed to write a high level design document to pull out the remaining uncertainties, and aim to get it over the line in Wallaby. ## Switching Docker storage from devicemapper to overlay2 We switched the default Docker storage driver from devicemapper to overlay2 in Victoria. For existing users of devicemapper, the plan is to try to ensure they are migrated to overlay2 during CentOS 8 migration. Further, we will deprecate devicemapper on stable branches, and require users to take some action (set a variable) to allow its use. This should deter new users from using devicemapper, without completely breaking existing users. # Switch to NetworkManager? jovial proposed this discussion, as he likes the checkpoint/restore feature of NetworkManager. There are various ways to interface with NM, including nm-cli, an ansible module, templated config files + nmcli con reload. ## Strip out Grafana post configure functionality and move it to Kolla-Ansible dougszu proposed this topic, to improve the separation of concerns between Kayobe and Kolla Ansible. It may also apply to setup we do for ironic. ## Create a reference custom playbook repo We have a stackhpc repo [9] with various useful playbooks and scripts. dougszu proposed making something more official. I suggested that Ansible collections could be used to improve the user experience with custom playbooks in external repos. ## Config gen on ansible control host This is something we've talked about for a while - offline generation of configuration, and potentially validating it in a CI pipeline. jovial noted the importance of being able to redact passwords. This is mostly dependent on ongoing changes to Kolla Ansible, but could be wrapped up nicely by Kayobe. ## Hashivault integration While we have integrated with Hashicorp vault for secret retrieval, the user experience could be better. We also lack support for pushing passwords generated by kolla up to Vault. This is likely to be a Kolla Ansible feature, plus some Kayobe integration. [1] https://review.opendev.org/681277 [2] https://review.opendev.org/759706 [3] https://review.opendev.org/695432 [4] https://github.com/dw/mitogen [5] https://github.com/stackhpc/ansible-scaling [6] https://www.haproxy.com/blog/hitless-reloads-with-haproxy-howto/ [7] https://review.opendev.org/755775 [8] https://review.opendev.org/734867 [9] https://github.com/stackhpc/kayobe-ops Cheers, Mark

1 0

Devstack installation failure
by Ratnopam Chakrabarti 30 Oct '20

30 Oct '20

Hi, Has anyone successfully installed devstack in last 2 weeks with stack.sh script?It was working well for me before that. I am seeing failures when I try to install on Ubuntu 18.04. Here's the trace - [Call Trace] ./stack.sh:1304:start_glance /home/stack/devstack/lib/glance:480:die [ERROR] /home/stack/devstack/lib/glance:480 g-api did not start Error on exit nova-compute: no process found neutron-dhcp-agent: no process found neutron-l3-agent: no process found neutron-metadata-agent: no process found neutron-openvswitch-agent: no process found git repo i am using to download devstack is https://git.openstack.org/openstack-dev/devstackI tried with with stable/victoria branch also, same issue. Any idea on how to solve this? Thanks

2 1

[tc] monthly meeting skip
by Mohammed Naser 30 Oct '20

30 Oct '20

Hello everyone, Our monthly meeting was scheduled for next Thursday, Nov 5th. Since the PTG took place this week, we will be skipping this month’s meeting and consider the PTG as our monthly meeting instead. Thanks, Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[ansible][tripleo][openstack-ansible-modules] Openstack Ansible modules PTG wrap up
by Sagi Shnaidman 30 Oct '20

30 Oct '20

Openstack Ansible modules PTG wrap up 1. We continue to align new features in SDK, OSC and modules a) need to complete switch of cloud layer to use ONLY proxy layer and not reimplement the APIs b) in Ansible modules we'd better to use cloud layer when it's available and not proxy layer 2. For exposing SDK logs when running modules, we need to find a right place to print them. Either it would be one of module returns or special plugin printing logs with more verbosity. The discussion will be in the maillist. 3. We will start developing unit tests for modules and run them with ansible-test. 4. Also need to rework our current test system and make it more atomic and add coverage. 5. We decided to align all *_info modules to one standard - <resource>_info, some of them named as <resource>s_info. 6. We'll need to generate documentation for modules and place it on docs.openstack.org if it's possible. Current documentation in Ansible covers the release that is built-in in Ansible and doesn't reflect last changes. 7. Effort of moving modules to use a single OpenstackModule class will continue. 8. Transition and adding new baremetal modules will continue as well. Thanks -- Best regards Sagi Shnaidman

1 0

Re: [Openstack][cinder] dell unity iscsi faulty devices
by Gorka Eguileor 30 Oct '20

30 Oct '20

On 30/10, Ignazio Cassano wrote: > Please, se the last email where I upgraded to the last openstack nova on > queens. > [root@compute-0 nova]# rpm -qa|grep queens > centos-release-openstack-queens-1-2.el7.centos.noarch > [root@compute-0 nova]# rpm -qa|grep nova > openstack-nova-compute-17.0.13-1.el7.noarch > openstack-nova-common-17.0.13-1.el7.noarch > python-nova-17.0.13-1.el7.noarch > python2-novaclient-10.1.0-1.el7.noarch > > I sent you the logs on the update release. > I am not so skilled for reading fine logs output about this issue. > Sorry > Ignazio > Hi, I missed that email and the attachment, sorry. The logs you sent me were missing most of the connect_volume call, and only the end of the call was present, but I think it doesn't matter as I see what the problem is. The problem is that some of the nodes and sessions are duplicated. An example of a duplicated node: tcp: [3] 10.102.189.156:3260,15 iqn.1992-04.com.emc:cx.ckm00200502005.b11 (non-flash) tcp: [4] 10.102.189.156:3260,15 iqn.1992-04.com.emc:cx.ckm00200502005.b11 (non-flash) An example of that node's duplicated session: tcp: [3] 10.102.189.156:3260,15 iqn.1992-04.com.emc:cx.ckm00200502005.b11 (non-flash) tcp: [4] 10.102.189.156:3260,15 iqn.1992-04.com.emc:cx.ckm00200502005.b11 (non-flash) And os-brick is not prepared to handle that, because it is programmed to reuse the nodes and sesssions. So on disconnect it get's the first of each to look for the volumes provided by it. In the example of the duplicated node-session aboveit sees that it provides /dev/sdd, but that is not one of the disks that belong to the multipath that we are disconnecting, so it gets ignored. The volume we are looking for it's probably on the second session. So from this point forward (where we have duplicated node-sessions) it will not work again. I recommend you clean up that system so that you don't have duplicated nodes and sessions before trying to do a VM migration with a single volume attached. If that works, then try to attach 2 volumes on instances on the same host and see if the nodes and sessions are duplicated. Cheers, Gorka. > Il giorno ven 30 ott 2020 alle ore 09:27 Gorka Eguileor <geguileo(a)redhat.com> > ha scritto: > > > On 30/10, Ignazio Cassano wrote: > > > Hello, these are versions we are using: > > > [root@podto2-kvm02 ansible]# rpm -qa|grep queens > > > centos-release-openstack-queens-1-2.el7.centos.noarch > > > [root@podto2-kvm02 ansible]# rpm -qa|grep nova > > > openstack-nova-common-17.0.11-1.el7.noarch > > > python2-novaclient-10.1.0-1.el7.noarch > > > openstack-nova-compute-17.0.11-1.el7.noarch > > > python-nova-17.0.11-1.el7.noarch > > > > > > Cheers,Gorka. > > > > Hi, > > > > That release has the Nova bug fix, so Nova should not be calling Cinder > > to do an initialize connection on the source on the post-migration step > > anymore. > > > > I recommend comparing the connection info passed to connect_volume when > > the volume is attached on the source host and when it's disconnected on > > the post-migration step on the source host. > > > > Cheers, > > Gorka. > > > > > > > > > > > > > [1]: https://bugs.launchpad.net/nova/+bug/1754716 > > > > [2]: > > > > > > https://github.com/openstack/nova/commit/013f421bca4067bd430a9fac1e3b290cf1… > > > > > > > > > > > > > > > > > > > Il giorno gio 29 ott 2020 alle ore 09:12 Gorka Eguileor < > > > > geguileo(a)redhat.com> > > > > > ha scritto: > > > > > > > > > > > On 28/10, Ignazio Cassano wrote: > > > > > > > Hello Gorka, I would like to know if with unity iscsi driver, I > > must > > > > > > > configure iscsi initiator on both compute and controller nodes. > > > > > > > At this time I installed and cinfigured iscsi initiator only on > > > > compute > > > > > > > nodes and I got a lot of faulty devices when volumes ate > > detached. > > > > > > > Thanks > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Both compute and controller nodes are in the data path. Computes > > when > > > > > > instances use the volumes, and controllers when we create volume > > from > > > > > > images, do generic volume migrations, create or restore backups, > > etc. > > > > > > > > > > > > Unless your deployment isn't doing any of the Cinder operations > > that > > > > > > involve the data plane, you'll have to configure iSCSI on the > > > > controller > > > > > > as well. > > > > > > > > > > > > Having said that, whether you configure the iSCSI initiator or not > > on > > > > > > the controller will have no effect on the paths used by the > > compute. > > > > > > > > > > > > I've seen the iSCSI initiator going crazy when the iscsid and the > > > > > > iscsiadm are from different versions. I've seen this in > > containerized > > > > > > environments. > > > > > > > > > > > > Faulty paths on multipathing is a tricky business, because there > > are > > > > > > different checkers, some generic (readsector0, tur, directio) and > > some > > > > > > vendor specific (emc_clarrion, hp_wd, rdac), and each one behaves > > in a > > > > > > different way. > > > > > > > > > > > > If you have a multipath device with faulty paths, that you think > > should > > > > > > not be faulty, you should look into what's going on with those > > paths: > > > > > > > > > > > > - Confirm that the device is still in the system under /dev/XYZ > > > > > > - Confirm in your storage array's console/webconsole that the > > volume is > > > > > > still mapped on that target-portal to that host's iscsi initiator > > > > > > name. > > > > > > - Confirm you can read the faulty devices with dd on the host > > > > > > - Confirm that the WWN of the device is the same in all the paths > > > > (using > > > > > > /lib/udev/scsi_id) > > > > > > - Finally look into what checker is multipath using for your device > > > > > > (sometimes checkers have bugs). > > > > > > > > > > > > Cheers, > > > > > > Gorka. > > > > > > > > > > > > > > > > > > > > > > > > > > Il Mar 20 Ott 2020, 19:58 Gorka Eguileor <geguileo(a)redhat.com> > > ha > > > > > > scritto: > > > > > > > > > > > > > > > On 20/10, Ignazio Cassano wrote: > > > > > > > > > This is the entre log from when the migration started: > > > > > > > > > > > > > > > > > > http://paste.openstack.org/show/799199/ > > > > > > > > > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > There are no os-brick calls in there. :-( > > > > > > > > > > > > > > > > You should look for the call to connect_volume that should have > > > > > > > > something like: > > > > > > > > > > > > > > > > ==> disconnect_volume: call "{'args': > > > > > > > > (<os_brick.initiator.connectors.iscsi > > > > > > > > > > > > > > > > And the second parameter to that call is a dictionary where you > > > > can see > > > > > > > > the target_lun, target_luns, target_portals, target_portal, > > > > target_iqn, > > > > > > > > target_iqns... This will allow us to check if we are actually > > > > > > connected > > > > > > > > to those targets-portals > > > > > > > > > > > > > > > > The third parameter should contain two things that are > > relevant, > > > > the > > > > > > > > scsi_wwn and the path. You can check if the path exists and if > > > > that > > > > > > > > path actually has that wwn using /lib/udev/scsi_id --page 0x83 > > > > > > > > --whitelisted $path > > > > > > > > > > > > > > > > Those are the things I would check, because the only reason I > > can > > > > think > > > > > > > > that os-brick is not disconnecting any volumes are that the > > > > connection > > > > > > > > info is not right, or that the volume is no longer connected. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Gorka. > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno mar 20 ott 2020 alle ore 11:23 Gorka Eguileor < > > > > > > > > geguileo(a)redhat.com> > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > > > > > On 20/10, Ignazio Cassano wrote: > > > > > > > > > > > Hello Gorka,this is what happens on nova compute with > > debug > > > > > > enabled, > > > > > > > > > > when I > > > > > > > > > > > migrate an instance with iscsi volumes ( note > > Disconnecting > > > > > > from[] > > > > > > > > should > > > > > > > > > > > be the issue): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The disconnect from [] is the right clue, not necessarily > > the > > > > > > issue. > > > > > > > > > > > > > > > > > > > > OS-Brick is saying that for the connection information > > that has > > > > > > been > > > > > > > > > > passed in the "disconnect_volume" call (which is not > > present > > > > in the > > > > > > > > > > emailed logs) there are no volumes present in the system. > > > > > > > > > > > > > > > > > > > > You should check the connection info that Nova is passing > > to > > > > > > > > > > disconnect_volume and confirm if that data is correct. For > > > > example > > > > > > > > > > checking if the path present in the connection info > > dictionary > > > > is > > > > > > the > > > > > > > > > > same as the one in the instance's XML dump, or if the LUN > > from > > > > the > > > > > > > > > > connection info dict is actually present in the system. > > > > > > > > > > > > > > > > > > > > There are multiple reasons why Nova could be passing the > > wrong > > > > > > > > > > connection info to os-brick. The ones that come to mind > > are: > > > > > > > > > > > > > > > > > > > > - There was a failed migration at some point, and Nova > > didn't > > > > > > rollback > > > > > > > > > > the connection info on the BDM table. > > > > > > > > > > - Nova is calling multiple times initialize_connection on > > > > Cinder > > > > > > for > > > > > > > > the > > > > > > > > > > same host and the driver being used is not idempotent. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gorka. > > > > > > > > > > > > > > > > > > > > > stderr= _run_iscsiadm_bare > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:1122 > > > > > > > > > > > 2020-10-20 09:52:33.066 132171 DEBUG > > > > > > > > os_brick.initiator.connectors.iscsi > > > > > > > > > > > [-] iscsi session list stdout=tcp: [10] > > 10.138.209.48:3260,9 > > > > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.a3 (non-flash) > > > > > > > > > > > tcp: [11] 10.138.215.17:3260,8 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.a2 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [12] 10.138.215.17:3260,8 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.a2 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [13] 10.138.215.18:3260,7 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.b2 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [14] 10.138.215.18:3260,7 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.b2 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [15] 10.138.209.47:3260,6 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.b3 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [16] 10.138.209.47:3260,6 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.b3 > > > > > > > > > > > (non-flash) > > > > > > > > > > > tcp: [9] 10.138.209.48:3260,9 > > > > > > > > iqn.1992-04.com.emc:cx.ckm00184400687.a3 > > > > > > > > > > > (non-flash) > > > > > > > > > > > stderr= _run_iscsi_session > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:1111 > > > > > > > > > > > 2020-10-20 09:52:33.078 132171 DEBUG > > > > > > > > os_brick.initiator.connectors.iscsi > > > > > > > > > > > [-] Resulting device map defaultdict(<function <lambda> > > at > > > > > > > > > > 0x7f4f1b1f7cf8>, > > > > > > > > > > > {(u'10.138.215.17:3260', > > > > > > > > u'iqn.1992-04.com.emc:cx.ckm00184400687.a2'): > > > > > > > > > > > (set([]), set([u'sdg', u'sdi'])), (u'10.138.209.47:3260 > > ', > > > > > > > > > > > u'iqn.1992-04.com.emc:cx.ckm00184400687.b3'): (set([]), > > > > > > set([u'sdo', > > > > > > > > > > > u'sdq'])), (u'10.138.209.48:3260', > > > > > > > > > > > u'iqn.1992-04.com.emc:cx.ckm00184400687.a3'): (set([]), > > > > > > set([u'sdd', > > > > > > > > > > > u'sdb'])), (u'10.138.215.18:3260', > > > > > > > > > > > u'iqn.1992-04.com.emc:cx.ckm00184400687.b2'): (set([]), > > > > > > set([u'sdm', > > > > > > > > > > > u'sdk']))}) _get_connection_devices > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:844 > > > > > > > > > > > 2020-10-20 09:52:33.078 132171 DEBUG > > > > > > > > os_brick.initiator.connectors.iscsi > > > > > > > > > > > [-] Disconnecting from: [] _disconnect_connection > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:1099 > > > > > > > > > > > 2020-10-20 09:52:33.079 132171 DEBUG > > > > oslo_concurrency.lockutils > > > > > > [-] > > > > > > > > Lock > > > > > > > > > > > "connect_volume" released by > > > > > > > > > > > "os_brick.initiator.connectors.iscsi.disconnect_volume" > > :: > > > > held > > > > > > > > 1.058s > > > > > > > > > > > inner > > > > > > > > > > /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:339 > > > > > > > > > > > 2020-10-20 09:52:33.079 132171 DEBUG > > > > > > > > os_brick.initiator.connectors.iscsi > > > > > > > > > > > [-] <== disconnect_volume: return (1057ms) None > > > > > > trace_logging_wrapper > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/utils.py:170 > > > > > > > > > > > 2020-10-20 09:52:33.079 132171 DEBUG > > > > > > nova.virt.libvirt.volume.iscsi > > > > > > > > [-] > > > > > > > > > > > [instance: 0c846f66-f194-40de-b31e-d53652570fa7] > > Disconnected > > > > > > iSCSI > > > > > > > > > > Volume > > > > > > > > > > > disconnect_volume > > > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/iscsi.py:78 > > > > > > > > > > > 2020-10-20 09:52:33.080 132171 DEBUG os_brick.utils [-] > > ==> > > > > > > > > > > > get_connector_properties: call u"{'execute': None, > > 'my_ip': > > > > > > > > > > > '10.138.208.178', 'enforce_multipath': True, 'host': > > > > > > > > 'podiscsivc-kvm02', > > > > > > > > > > > 'root_helper': 'sudo nova-rootwrap > > /etc/nova/rootwrap.conf', > > > > > > > > 'multipath': > > > > > > > > > > > True}" trace_logging_wrapper > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/utils.py:146 > > > > > > > > > > > 2020-10-20 09:52:33.125 132171 DEBUG > > > > os_brick.initiator.linuxfc > > > > > > [-] > > > > > > > > No > > > > > > > > > > > Fibre Channel support detected on system. get_fc_hbas > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/linuxfc.py:157 > > > > > > > > > > > 2020-10-20 09:52:33.126 132171 DEBUG > > > > os_brick.initiator.linuxfc > > > > > > [-] > > > > > > > > No > > > > > > > > > > > Fibre Channel support detected on system. get_fc_hbas > > > > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/initiator/linuxfc.py:157 > > > > > > > > > > > 2020-10-20 09:52:33.145 132171 DEBUG os_brick.utils [-] > > <== > > > > > > > > > > > get_connector_properties: return (61ms) {'initiator': > > > > > > > > > > > u'iqn.1994-05.com.redhat:fbfdc37eed4c', 'ip': > > > > u'10.138.208.178', > > > > > > > > 'system > > > > > > > > > > > uuid': u'4C4C4544-0051-4E10-8057-B6C04F425932', > > 'platform': > > > > > > > > u'x86_64', > > > > > > > > > > > 'host': u'podiscsivc-kvm02', 'do_local_attach': False, > > > > 'os_type': > > > > > > > > > > > u'linux2', 'multipath': True} trace_logging_wrapper > > > > > > > > > > > /usr/lib/python2.7/site-packages/os_brick/utils.py:170 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > > > > Il giorno gio 15 ott 2020 alle ore 10:57 Gorka Eguileor < > > > > > > > > > > geguileo(a)redhat.com> > > > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > > > > > > > > > On 14/10, Ignazio Cassano wrote: > > > > > > > > > > > > > Hello, thank you for the answer. > > > > > > > > > > > > > I am using os-brick 2.3.8 but I got same issues on > > stein > > > > with > > > > > > > > > > os.brick > > > > > > > > > > > > 2.8 > > > > > > > > > > > > > For explain better the situation I send you the > > output of > > > > > > > > multipath > > > > > > > > > > -ll > > > > > > > > > > > > on > > > > > > > > > > > > > a compute node: > > > > > > > > > > > > > root@podvc-kvm01 ansible]# multipath -ll > > > > > > > > > > > > > Oct 14 18:50:01 | sdbg: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdbe: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdbd: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdbf: alua not supported > > > > > > > > > > > > > 360060160f0d049007ab7275f743d0286 dm-11 DGC > > ,VRAID > > > > > > > > > > > > > size=30G features='1 retain_attached_hw_handler' > > > > hwhandler='1 > > > > > > > > alua' > > > > > > > > > > wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=0 status=enabled > > > > > > > > > > > > > | |- 15:0:0:71 sdbg 67:160 failed faulty running > > > > > > > > > > > > > | `- 12:0:0:71 sdbe 67:128 failed faulty running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=0 status=enabled > > > > > > > > > > > > > |- 11:0:0:71 sdbd 67:112 failed faulty running > > > > > > > > > > > > > `- 13:0:0:71 sdbf 67:144 failed faulty running > > > > > > > > > > > > > 360060160f0d049004cdb615f52343fdb dm-8 DGC ,VRAID > > > > > > > > > > > > > size=80G features='2 queue_if_no_path > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 15:0:0:210 sdau 66:224 active ready running > > > > > > > > > > > > > | `- 12:0:0:210 sdas 66:192 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 11:0:0:210 sdar 66:176 active ready running > > > > > > > > > > > > > `- 13:0:0:210 sdat 66:208 active ready running > > > > > > > > > > > > > 360060160f0d0490034aa645fe52265eb dm-12 DGC > > ,VRAID > > > > > > > > > > > > > size=100G features='2 queue_if_no_path > > > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 12:0:0:177 sdbi 67:192 active ready running > > > > > > > > > > > > > | `- 15:0:0:177 sdbk 67:224 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 11:0:0:177 sdbh 67:176 active ready running > > > > > > > > > > > > > `- 13:0:0:177 sdbj 67:208 active ready running > > > > > > > > > > > > > 360060160f0d04900159f225fd6126db9 dm-6 DGC ,VRAID > > > > > > > > > > > > > size=40G features='2 queue_if_no_path > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 11:0:0:26 sdaf 65:240 active ready running > > > > > > > > > > > > > | `- 13:0:0:26 sdah 66:16 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 12:0:0:26 sdag 66:0 active ready running > > > > > > > > > > > > > `- 15:0:0:26 sdai 66:32 active ready running > > > > > > > > > > > > > Oct 14 18:50:01 | sdba: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdbc: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdaz: alua not supported > > > > > > > > > > > > > Oct 14 18:50:01 | sdbb: alua not supported > > > > > > > > > > > > > 360060160f0d049007eb7275f93937511 dm-10 DGC > > ,VRAID > > > > > > > > > > > > > size=40G features='1 retain_attached_hw_handler' > > > > hwhandler='1 > > > > > > > > alua' > > > > > > > > > > wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=0 status=enabled > > > > > > > > > > > > > | |- 12:0:0:242 sdba 67:64 failed faulty running > > > > > > > > > > > > > | `- 15:0:0:242 sdbc 67:96 failed faulty running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=0 status=enabled > > > > > > > > > > > > > |- 11:0:0:242 sdaz 67:48 failed faulty running > > > > > > > > > > > > > `- 13:0:0:242 sdbb 67:80 failed faulty running > > > > > > > > > > > > > 360060160f0d049003a567c5fb72201e8 dm-7 DGC ,VRAID > > > > > > > > > > > > > size=40G features='2 queue_if_no_path > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 12:0:0:57 sdbq 68:64 active ready running > > > > > > > > > > > > > | `- 15:0:0:57 sdbs 68:96 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 11:0:0:57 sdbp 68:48 active ready running > > > > > > > > > > > > > `- 13:0:0:57 sdbr 68:80 active ready running > > > > > > > > > > > > > 360060160f0d04900c120625f802ea1fa dm-9 DGC ,VRAID > > > > > > > > > > > > > size=25G features='2 queue_if_no_path > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 11:0:0:234 sdav 66:240 active ready running > > > > > > > > > > > > > | `- 13:0:0:234 sdax 67:16 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 15:0:0:234 sday 67:32 active ready running > > > > > > > > > > > > > `- 12:0:0:234 sdaw 67:0 active ready running > > > > > > > > > > > > > 360060160f0d04900b8b0615fb14ef1bd dm-3 DGC ,VRAID > > > > > > > > > > > > > size=50G features='2 queue_if_no_path > > > > > > retain_attached_hw_handler' > > > > > > > > > > > > > hwhandler='1 alua' wp=rw > > > > > > > > > > > > > |-+- policy='round-robin 0' prio=50 status=active > > > > > > > > > > > > > | |- 11:0:0:11 sdan 66:112 active ready running > > > > > > > > > > > > > | `- 13:0:0:11 sdap 66:144 active ready running > > > > > > > > > > > > > `-+- policy='round-robin 0' prio=10 status=enabled > > > > > > > > > > > > > |- 12:0:0:11 sdao 66:128 active ready running > > > > > > > > > > > > > `- 15:0:0:11 sdaq 66:160 active ready running > > > > > > > > > > > > > > > > > > > > > > > > > > The active running are related to running virtual > > > > machines. > > > > > > > > > > > > > The faulty are related to virtual macnines migrated > > on > > > > other > > > > > > kvm > > > > > > > > > > nodes. > > > > > > > > > > > > > Every volume has 4 path because iscsi on unity needs > > two > > > > > > > > different > > > > > > > > > > vlans, > > > > > > > > > > > > > each one with 2 addresses. > > > > > > > > > > > > > I think this issue can be related to os-brick because > > > > when I > > > > > > > > migrate > > > > > > > > > > a > > > > > > > > > > > > > virtual machine from host A host B in the cova > > compute > > > > log on > > > > > > > > host A > > > > > > > > > > I > > > > > > > > > > > > read: > > > > > > > > > > > > > 2020-10-13 10:31:02.769 118727 DEBUG > > > > > > > > > > os_brick.initiator.connectors.iscsi > > > > > > > > > > > > > [req-771ede8c-6e1b-4f3f-ad4a-1f6ed820a55c > > > > > > > > > > > > 66adb965bef64eaaab2af93ade87e2ca > > > > > > > > > > > > > 85cace94dcc7484c85ff9337eb1d0c4c - default default] > > > > > > > > *Disconnecting > > > > > > > > > > from: > > > > > > > > > > > > []* > > > > > > > > > > > > > > > > > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > That's definitely the right clue!! Though I don't > > fully > > > > agree > > > > > > with > > > > > > > > > > this > > > > > > > > > > > > being an os-brick issue just yet. ;-) > > > > > > > > > > > > > > > > > > > > > > > > Like I mentioned before, RCA is usually non-trivial, > > and > > > > > > > > explaining how > > > > > > > > > > > > to debug these issues over email is close to > > impossible, > > > > but if > > > > > > > > this > > > > > > > > > > > > were my system, and assuming you have tested normal > > > > > > attach/detach > > > > > > > > > > > > procedure and is working fine, this is what I would do: > > > > > > > > > > > > > > > > > > > > > > > > - Enable DEBUG logs on Nova compute node (I believe you > > > > already > > > > > > > > have) > > > > > > > > > > > > - Attach a new device to an instance on that node with > > > > --debug > > > > > > to > > > > > > > > get > > > > > > > > > > > > the request id > > > > > > > > > > > > - Get the connection information dictionary that > > os-brick > > > > > > receives > > > > > > > > on > > > > > > > > > > > > the call to connect_volume for that request, and the > > data > > > > > > that > > > > > > > > > > > > os-brick returns to Nova on that method call > > completion. > > > > > > > > > > > > - Check if the returned data to Nova is a multipathed > > > > device or > > > > > > > > not (in > > > > > > > > > > > > 'path'), and whether we have the wwn or not (in > > > > > > 'scsi_wwn'). It > > > > > > > > > > > > should be a multipath device, and then I would check > > its > > > > > > status > > > > > > > > in > > > > > > > > > > the > > > > > > > > > > > > multipath daemon. > > > > > > > > > > > > - Now do the live migration (with --debug to get the > > > > request > > > > > > id) > > > > > > > > and > > > > > > > > > > see > > > > > > > > > > > > what information Nova passes in that request to > > > > os-brick's > > > > > > > > > > > > disconnect_volume. > > > > > > > > > > > > - Is it the same? Then it's likely an os-brick issue, > > > > and I > > > > > > can > > > > > > > > have > > > > > > > > > > a > > > > > > > > > > > > look at the logs if you put the logs for that > > os-brick > > > > > > detach > > > > > > > > > > > > process in a pastebin [1]. > > > > > > > > > > > > - Is it different? Then it's either a Nova bug or a > > > > Cinder > > > > > > driver > > > > > > > > > > > > specific bug. > > > > > > > > > > > > - Is there a call from Nova to Cinder, in the > > migration > > > > > > > > request, > > > > > > > > > > for > > > > > > > > > > > > that same volume to initialize_connection > > passing the > > > > > > source > > > > > > > > host > > > > > > > > > > > > connector info (info from the host that is > > currently > > > > > > > > attached)? > > > > > > > > > > > > If there is a call, check if the returned data is > > > > > > different > > > > > > > > from > > > > > > > > > > > > the one we used to do the attach, if that's the > > case > > > > then > > > > > > > > it's a > > > > > > > > > > > > Nova and Cinder driver bug that was solved on the > > > > Nova > > > > > > side > > > > > > > > in > > > > > > > > > > > > 17.0.10 [2]. > > > > > > > > > > > > - If there's no call to Cinder's > > > > initialize_connection, the > > > > > > > > it's > > > > > > > > > > > > most likely a Nova bug. Try to find out if this > > > > > > connection > > > > > > > > info > > > > > > > > > > > > makes any sense for that host (LUN, target, > > etc.) or > > > > if > > > > > > this > > > > > > > > is > > > > > > > > > > > > the one from the destination volume. > > > > > > > > > > > > > > > > > > > > > > > > I hope this somehow helps. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Gorka. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]: http://paste.openstack.org/ > > > > > > > > > > > > [2]: https://review.opendev.org/#/c/637827/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno mer 14 ott 2020 alle ore 13:41 Gorka > > Eguileor < > > > > > > > > > > > > geguileo(a)redhat.com> > > > > > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 09/10, Ignazio Cassano wrote: > > > > > > > > > > > > > > > Hello Stackers, I am using dell emc iscsi driver > > on > > > > my > > > > > > > > centos 7 > > > > > > > > > > > > queens > > > > > > > > > > > > > > > openstack. It works and instances work as well > > but on > > > > > > compute > > > > > > > > > > nodes I > > > > > > > > > > > > > > got a > > > > > > > > > > > > > > > lot a faulty device reported by multipath il > > comand. > > > > > > > > > > > > > > > I do know why this happens, probably attacching > > and > > > > > > detaching > > > > > > > > > > > > volumes and > > > > > > > > > > > > > > > live migrating instances do not close something > > well. > > > > > > > > > > > > > > > I read this can cause serious performances > > problems > > > > on > > > > > > > > compute > > > > > > > > > > nodes. > > > > > > > > > > > > > > > Please, any workaround and/or patch is suggested > > ? > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are many, many, many things that could be > > > > happening > > > > > > > > there, > > > > > > > > > > and > > > > > > > > > > > > > > it's not usually trivial doing the RCA, so the > > > > following > > > > > > > > questions > > > > > > > > > > are > > > > > > > > > > > > > > just me hoping this is something "easy" to find > > out. > > > > > > > > > > > > > > > > > > > > > > > > > > > > What os-brick version from Queens are you running? > > > > Latest > > > > > > > > > > (2.3.9), or > > > > > > > > > > > > > > maybe one older than 2.3.3? > > > > > > > > > > > > > > > > > > > > > > > > > > > > When you say you have faulty devices reported, are > > > > these > > > > > > faulty > > > > > > > > > > devices > > > > > > > > > > > > > > alone in the multipath DM? Or do you have some > > faulty > > > > ones > > > > > > with > > > > > > > > > > some > > > > > > > > > > > > > > that are ok? > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are some OK and some that aren't, are they > > > > > > consecutive > > > > > > > > > > > > devices? > > > > > > > > > > > > > > (as in /dev/sda /dev/sdb etc). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Gorka. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

2 2

Re: [kolla] Setting up eth1 on VM for AIO
by Braden, Albert 30 Oct '20

30 Oct '20

From: Mark Goddard <mark(a)stackhpc.com> Sent: Friday, October 30, 2020 4:37 AM To: Radosław Piliszek <radoslaw.piliszek(a)gmail.com> Cc: Braden, Albert <C-Albert.Braden(a)charter.com>; OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [kolla] Setting up eth1 on VM for AIO On Thu, 29 Oct 2020 at 16:20, Radosław Piliszek <radoslaw.piliszek(a)gmail.com<mailto:radoslaw.piliszek@gmail.com>> wrote: Hi Albert! Sorry for top posting but I don't really see which part to quote would be best so they all lose. :D Indeed, it's tricky to handle this if you are not a fan of linux networking. I guess we should document an example way.... Anyhow, the way e.g. Kayobe handles it for users (as it deals with baremetal details) is to use bridges and veths. Basically, you create a bridge, attach it to the expected interface, set any networking you still want on that network for this host on this bridge. Then, you create a veth pair and connect one end to it and the second one is given to neutron. >Alternatively, if this is just for development, you can use a dummy interface. > >ip link add link eth1 type dummy > >It's not persistent, but good enough for testing. If you need external network access from it you could add a MASQUERADE iptables rule and enable the IP >forwarding sysctl. That seems to be working. After googling a bit I was able to make it persistent: [root@adjutant-poc ~]# cat /etc/modules-load.d/dummy.conf dummy [root@adjutant-poc ~]# cat /etc/modprobe.d/dummy.conf install dummy /sbin/modprobe --ignore-install dummy; /sbin/ip link set name eth1 dev dummy0 [root@adjutant-poc ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 NAME=eth1 BOOTPROTO=none DEVICE=eth1 ONBOOT=yes TYPE=Ethernet NM_CONTROLLED=no [root@adjutant-poc ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:22:c4:e2 brd ff:ff:ff:ff:ff:ff inet 192.168.1.83/22 brd 192.168.3.255 scope global dynamic eth0 valid_lft 85821sec preferred_lft 85821sec inet6 fe80::f816:3eff:fe22:c4e2/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 7e:e1:fe:31:c9:2e brd ff:ff:ff:ff:ff:ff inet6 fe80::7ce1:feff:fe31:c92e/64 scope link valid_lft forever preferred_lft forever -yoctozepto On Thu, Oct 29, 2020 at 12:49 PM Braden, Albert <C-Albert.Braden(a)charter.com<mailto:C-Albert.Braden@charter.com>> wrote: > > I’m trying to setup an allinone kolla-ansible Train POC on a VM, and I’m following the instructions here: > > > > https://docs.openstack.org/kolla-ansible/train/user/quickstart.html > > > > Under “Prepare initial configuration” where it talks about globals.yml, it says I need 2 network interfaces: > > > > network_interface: "eth0" > > neutron_external_interface: "eth1" > > > > My VM has a private IP and a floating IP that I use to ssh to it: > > > > | ID | Name | Status | Networks | Image | Flavor | > > | 41f6782a-8ca8-4ab4-8fdc-776584139ba0 | adjutant-poc | ACTIVE | private=<primary IP>, <floating IP> | | s1-standard-08 | > > > > I tried various options for eth1 but I can’t seem to get it to work: > > > > [root@adjutant-poc network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 > > BOOTPROTO=dhcp > > DEVICE=eth1 > > ONBOOT=yes > > TYPE=Ethernet > > NM_CONTROLLED=no > > > > I tried creating another port and adding it but that didn’t seem to make a difference. What am I doing wrong? Do I really need 2 network interfaces on the VM? If so, what’s the correct way to add one? > > > > [root@adjutant-poc network-scripts]# service network restart > > Restarting network (via systemctl): Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details. > > [FAILED] > > > > Log: > > > > http://paste.debian.net/1168982/ > > > > I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. > > > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

1 0

[ironic] SPUC winter season
by Dmitry Tantsur 30 Oct '20

30 Oct '20

Boo! It's SPUC time again! Ironicers, their pet AIs, friendly stackers, as well as significant others and fluffy overladies and overlords, are welcome! For those who don't know, Sanity Preserving Un-Conference is a series of Friday calls for keeping (the remainings) of our sanity in these difficult times. It's goal is to let people virtually socialize and help brighten up lives for each other. Work achievements? A new hobby? A hilarious story? Funny things your kid did at 4am? The first words from your pizza dough that you forgot in the fridge during the previous lockdown? Anything that makes you and others happier is on-topic! Due to an increasing number of APAC contributors, I would like two pick slots: one in APAC evening/Europe morning, the other in Europe morning/US afternoon. Please vote in the doodle: https://doodle.com/poll/tw72utagidz2nac3 Cheers, Dmitry -- 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

4 6

[openstack][nova] urgent compute in evacuate state
by Ignazio Cassano 30 Oct '20

30 Oct '20

Hello Guys, I have a node in evacuate state....how exit from this state ? Thanks Ignazio

2 6

[kolla] Setting up eth1 on VM for AIO
by Braden, Albert 30 Oct '20

30 Oct '20

I'm trying to setup an allinone kolla-ansible Train POC on a VM, and I'm following the instructions here: https://docs.openstack.org/kolla-ansible/train/user/quickstart.html Under "Prepare initial configuration" where it talks about globals.yml, it says I need 2 network interfaces: network_interface: "eth0" neutron_external_interface: "eth1" My VM has a private IP and a floating IP that I use to ssh to it: | ID | Name | Status | Networks | Image | Flavor | | 41f6782a-8ca8-4ab4-8fdc-776584139ba0 | adjutant-poc | ACTIVE | private=<primary IP>, <floating IP> | | s1-standard-08 | I tried various options for eth1 but I can't seem to get it to work: [root@adjutant-poc network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 BOOTPROTO=dhcp DEVICE=eth1 ONBOOT=yes TYPE=Ethernet NM_CONTROLLED=no I tried creating another port and adding it but that didn't seem to make a difference. What am I doing wrong? Do I really need 2 network interfaces on the VM? If so, what's the correct way to add one? [root@adjutant-poc network-scripts]# service network restart Restarting network (via systemctl): Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details. [FAILED] Log: http://paste.debian.net/1168982/ I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

3 2

[Openstack][cinder] dell unity iscsi faulty devices
by Ignazio Cassano 30 Oct '20

30 Oct '20

Hello Stackers, I am using dell emc iscsi driver on my centos 7 queens openstack. It works and instances work as well but on compute nodes I got a lot a faulty device reported by multipath il comand. I do know why this happens, probably attacching and detaching volumes and live migrating instances do not close something well. I read this can cause serious performances problems on compute nodes. Please, any workaround and/or patch is suggested ? Regards Ignazio

2 18