Upcoming Meetups
by Rain Leander
The following are the meetups I'm aware of over the next two weeks where
OpenStack and/or RDO enthusiasts are likely to be present. If you know of
others, please let me know, and/or add them to http://rdoproject.org/events
If there's a meetup in your area, it'd be super keen if you attended, took
a few pictures and especially wrote up a summary of what was covered. And,
as always, if you give me enough notice, I can send swag along with you.
~Rain.
* Tuesday October 09 in Stockholm, SE: OpenStack Days Nordic - Stockholm
2018 - https://www.meetup.com/OpenStack-User-Group-Sweden/events/248260324/
* Tuesday October 09 in Reston, VA, US: Continuous Integration at Scale -
Running a Zuul CI Cloud -
https://www.meetup.com/OpenStack-Nova/events/255241322/
* Friday October 12 in Bangalore, IN: OpenStack Mini-Conf at OSI Days India
2018 - https://www.meetup.com/Indian-OpenStack-User-Group/events/254375680/
* Wednesday October 17 in Shanghai, CN: Kata Containers Meetup@Beijing -
https://www.meetup.com/Shanghai-OpenStack-Meetup/events/254371087/
* Wednesday October 17 in Leipzig, DE: 1. Meetup der OpenStack User Group
Leipzig -
https://www.meetup.com/OpenStack-User-Group-Leipzig/events/254455697/
* Thursday October 18 in San Diego, CA, US: Coffee & Clouds -
https://www.meetup.com/OpenStackSanDiego/events/255246646/
6 years, 1 month
Problems with Controller and Instance HA
by Cody
Hi everyone,
My cluster is deployed with both Controller and Instance HA. The deployment
completed without errors, but I noticed something strange from the 'pcs
status' output from the controllers:
Clone Set: compute-unfence-trigger-clone [compute-unfence-trigger]
Started: [ overcloud-novacompute-0 ]
Stopped: [ overcloud-controller-0 overcloud-controller-1
overcloud-controller-2 overcloud-novacompute-1 ]
nova-evacuate (ocf::openstack:NovaEvacuate): Started
overcloud-controller-0
stonith-fence_ipmilan-002590a2d2c7 (stonith:fence_ipmilan): Started
overcloud-controller-1
stonith-fence_ipmilan-002590a1c641 (stonith:fence_ipmilan): Started
overcloud-controller-2
stonith-fence_ipmilan-002590f25822 (stonith:fence_ipmilan): Started
overcloud-controller-0
stonith-fence_ipmilan-002590f3977a (stonith:fence_ipmilan): Started
overcloud-controller-2
stonith-fence_ipmilan-002590f2631a (stonith:fence_ipmilan): Started
overcloud-controller-1
Notice the stonith-fence_ipmilan lines showed incorrect hosts for the last
two devices. The MAC addresses are for the overcloud-novacompute-0 and
overcloud-novacompute-1, but it got started on the controller nodes. Is
this right?
There are also some failed actions from the status output:
Failed Actions:
* overcloud-novacompute-1_start_0 on overcloud-controller-2 'unknown error'
(1): call=3, status=Timed Out, exitreason='', last-rc-change='Wed Oct 3
03:48:55 2018', queued=0ms, exec=0ms
* overcloud-novacompute-1_start_0 on overcloud-controller-0 'unknown error'
(1): call=23, status=Timed Out, exitreason='', last-rc-change='Wed Oct 3
14:50:25 2018', queued=0ms, exec=0ms
* overcloud-novacompute-1_start_0 on overcloud-controller-1 'unknown error'
(1): call=3, status=Timed Out, exitreason='', last-rc-change='Wed Oct 3
03:47:51 2018', queued=0ms, exec=0ms
I can spin up VMs, but cannot do failover. If I manually trigger a crash on
one of the compute nodes, the affected VMs will remain at ERROR state and
the affected compute node will be unable to rejoin the cluster afterward.
After a manual reboot on the affected compute node, it cannot start the pcs
cluster service. Its container 'nova_compute' also remains unhealthy after
reboot, with the lastest 'docker logs' message as:
++ cat /run_command
+ CMD='/var/lib/nova/instanceha/check-run-nova-compute '
+ ARGS=
+ [[ ! -n '' ]]
+ . kolla_extend_start
++ [[ ! -d /var/log/kolla/nova ]]
+++ stat -c %a /var/log/kolla/nova
++ [[ 2755 != \7\5\5 ]]
++ chmod 755 /var/log/kolla/nova
++ . /usr/local/bin/kolla_nova_extend_start
+++ [[ ! -d /var/lib/nova/instances ]]
+ echo 'Running command:
'\''/var/lib/nova/instanceha/check-run-nova-compute '\'''
Running command: '/var/lib/nova/instanceha/check-run-nova-compute '
+ exec /var/lib/nova/instanceha/check-run-nova-compute
Waiting for fence-down flag to be cleared
Waiting for fence-down flag to be cleared
Waiting for fence-down flag to be cleared
Waiting for fence-down flag to be cleared
Waiting for fence-down flag to be cleared
Waiting for fence-down flag to be cleared
...
So I guess something may be wrong with fencing, but I have no idea what
caused it and how to fix it. Any helps/suggestions/opinions would be
greatly appreciated. Thank you very much.
Regards.
Cody
6 years, 1 month
Re: [rdo-users] requests requires chardet >= 3.0.2, < 3.1.0
by Haïkel Guémar
On 03/10/2018 11:02, Tobias Urdin wrote:
> Hello,
>
> This is an issue we've seen in the CentOS CI for Puppet OpenStack for a
> while as well.
> After talking to Alfredo on IRC he reported the following bug a while
> ago [1].
>
> Best regards
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1620221
>
No update for 6 weeks, it might be worth pinging jcline about it.
I mean I technically can fix it directly in Fedora but since it was
removed by another maintainer, it would be removed again.
Meanwhile, workaround has been built, and we can keep going.
https://review.rdoproject.org/r/16730
Regards,
H.
> On 10/03/2018 09:51 AM, Haïkel Guémar wrote:
>> On 02/10/2018 21:22, iain MacDonnell wrote:
>>> Not sure if this should go to -users or -dev (or somewhere else)...
>>>
>>> RDO (Rocky) ships with python2-requests-2.19.1-3.el7.noarch.rpm and
>>> python2-chardet-3.0.4-7.el7.noarch.rpm.
>>>
>>> The requests code has a hard-coded check for:
>>>
>>> # Check chardet for compatibility.
>>> major, minor, patch = chardet_version.split('.')[:3]
>>> major, minor, patch = int(major), int(minor), int(patch)
>>> # chardet >= 3.0.2, < 3.1.0
>>> assert major == 3
>>> assert minor < 1
>>> assert patch >= 2
>>>
>>> Unfortunately this requirement is not reflected in the
>>> python2-requests RPM, which just "requires" "python-chardet" (without
>>> any specific version). If the EL7-bundled version of python-chardet is
>>> already installed, and one installs python2-requests from the RDO
>>> repo, either directly or via dependency, python2-chardet does NOT get
>>> updated, which results in warnings like:
>>>
>>> # python -c 'import requests'
>>> /usr/lib/python2.7/site-packages/requests/__init__.py:91:
>>> RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.2.1) doesn't
>>> match a supported version!
>>> RequestsDependencyWarning)
>>> #
>>>
>>> I think that the python2-requests PRM needs an explicit "requires" for
>>> the specific version of python[2]-chardet. Anyone disagree? What's the
>>> right way to file a bug on this?
>>>
>>> TIA,
>>>
>>> ~iain
>>> _______________________________________________
>>> users mailing list
>>> users(a)lists.rdoproject.org
>>> http://lists.rdoproject.org/mailman/listinfo/users
>>>
>>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org
>>>
>> FYI, I acknowledge this issue so I should deliver a fix today.
>> About it, we're rebasing requests packages from Fedora but it seems that
>> they just dropped that lower version requirements for the same reason
>> [1] so reintroducing it there would not be constructive.
>> Nonetheless, we will fix it in RDO packages as it impacts EL7 users.
>>
>> Regards,
>> H.
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1589306
>>
>> _______________________________________________
>> users mailing list
>> users(a)lists.rdoproject.org
>> http://lists.rdoproject.org/mailman/listinfo/users
>>
>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org
>>
>
6 years, 1 month
Re: [rdo-users] requests requires chardet >= 3.0.2, < 3.1.0
by Haïkel Guémar
On 03/10/2018 11:02, Tobias Urdin wrote:
> Hello,
>
> This is an issue we've seen in the CentOS CI for Puppet OpenStack for a
> while as well.
> After talking to Alfredo on IRC he reported the following bug a while
> ago [1].
>
> Best regards
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1620221
>
No update since August, 22, it's worth pinging jcline about it.
Meanwhile, I have built a fixed package in CBS.
https://review.rdoproject.org/r/16730
> On 10/03/2018 09:51 AM, Haïkel Guémar wrote:
>> On 02/10/2018 21:22, iain MacDonnell wrote:
>>> Not sure if this should go to -users or -dev (or somewhere else)...
>>>
>>> RDO (Rocky) ships with python2-requests-2.19.1-3.el7.noarch.rpm and
>>> python2-chardet-3.0.4-7.el7.noarch.rpm.
>>>
>>> The requests code has a hard-coded check for:
>>>
>>> # Check chardet for compatibility.
>>> major, minor, patch = chardet_version.split('.')[:3]
>>> major, minor, patch = int(major), int(minor), int(patch)
>>> # chardet >= 3.0.2, < 3.1.0
>>> assert major == 3
>>> assert minor < 1
>>> assert patch >= 2
>>>
>>> Unfortunately this requirement is not reflected in the
>>> python2-requests RPM, which just "requires" "python-chardet" (without
>>> any specific version). If the EL7-bundled version of python-chardet is
>>> already installed, and one installs python2-requests from the RDO
>>> repo, either directly or via dependency, python2-chardet does NOT get
>>> updated, which results in warnings like:
>>>
>>> # python -c 'import requests'
>>> /usr/lib/python2.7/site-packages/requests/__init__.py:91:
>>> RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.2.1) doesn't
>>> match a supported version!
>>> RequestsDependencyWarning)
>>> #
>>>
>>> I think that the python2-requests PRM needs an explicit "requires" for
>>> the specific version of python[2]-chardet. Anyone disagree? What's the
>>> right way to file a bug on this?
>>>
>>> TIA,
>>>
>>> ~iain
>>> _______________________________________________
>>> users mailing list
>>> users(a)lists.rdoproject.org
>>> http://lists.rdoproject.org/mailman/listinfo/users
>>>
>>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org
>>>
>> FYI, I acknowledge this issue so I should deliver a fix today.
>> About it, we're rebasing requests packages from Fedora but it seems that
>> they just dropped that lower version requirements for the same reason
>> [1] so reintroducing it there would not be constructive.
>> Nonetheless, we will fix it in RDO packages as it impacts EL7 users.
>>
>> Regards,
>> H.
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1589306
>>
>> _______________________________________________
>> users mailing list
>> users(a)lists.rdoproject.org
>> http://lists.rdoproject.org/mailman/listinfo/users
>>
>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org
>>
>
6 years, 1 month
requests requires chardet >= 3.0.2, < 3.1.0
by iain MacDonnell
Not sure if this should go to -users or -dev (or somewhere else)...
RDO (Rocky) ships with python2-requests-2.19.1-3.el7.noarch.rpm and
python2-chardet-3.0.4-7.el7.noarch.rpm.
The requests code has a hard-coded check for:
# Check chardet for compatibility.
major, minor, patch = chardet_version.split('.')[:3]
major, minor, patch = int(major), int(minor), int(patch)
# chardet >= 3.0.2, < 3.1.0
assert major == 3
assert minor < 1
assert patch >= 2
Unfortunately this requirement is not reflected in the
python2-requests RPM, which just "requires" "python-chardet" (without
any specific version). If the EL7-bundled version of python-chardet is
already installed, and one installs python2-requests from the RDO
repo, either directly or via dependency, python2-chardet does NOT get
updated, which results in warnings like:
# python -c 'import requests'
/usr/lib/python2.7/site-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.2.1) doesn't
match a supported version!
RequestsDependencyWarning)
#
I think that the python2-requests PRM needs an explicit "requires" for
the specific version of python[2]-chardet. Anyone disagree? What's the
right way to file a bug on this?
TIA,
~iain
6 years, 1 month
Upcoming Meetups
by Rain Leander
The following are the meetups I'm aware of over the next two weeks where
OpenStack and/or RDO enthusiasts are likely to be present. If you know of
others, please let me know, and/or add them to http://rdoproject.org/events
If there's a meetup in your area, it'd be super keen if you attended, took
a few pictures and especially wrote up a summary of what was covered. And,
as always, if you give me enough notice, I can send swag along with you.
~Rain.
* Thursday October 04 in Bucharest, RO: OpenStack Romania Meetup - October
2018 meetup -
https://www.meetup.com/OpenStack-Bucharest-Romania-Meetup/events/254813224/
* Saturday October 06 in Littleton, CO, US: A Gentle, Hands-on Introduction
to OpenStack with David L. Willson -
https://www.meetup.com/sofreeus/events/254583920/
* Tuesday October 09 in Stockholm, SE: OpenStack Days Nordic - Stockholm
2018 - https://www.meetup.com/OpenStack-User-Group-Sweden/events/248260324/
* Friday October 12 in Bangalore, IN: OpenStack Mini-Conf at OSI Days India
2018 - https://www.meetup.com/Indian-OpenStack-User-Group/events/254375680/
--
K Rain Leander
OpenStack Community Liaison
Open Source and Standards Team
https://www.rdoproject.org/
http://community.redhat.com
6 years, 1 month
