3:22 a.m.
Hello,
This issue was discovered on Kolla train-centos8 images, but I assume
it applies to both Train and Ussuri for CentOS 8 in general, not just
to Kolla.
CloudKitty became timezone-aware in Train:
https://review.opendev.org/#/c/669192/
This code references tz.UTC from the dateutil library. However, this
was added only in dateutil 2.7.0, while train-centos8 Kolla images use
package python3-dateutil-2.6.1-6.el8.noarch.rpm, causing the error
captured at the end of this message [2].
I submitted a patch to raise the minimum requirement for dateutil in
cloudkitty: https://review.opendev.org/#/c/742477/
However, how are those requirements taken into consideration when
packaging OpenStack in RDO? RDO packages for CentOS7 provide
python2-dateutil-2.8.0-1.el7.noarch.rpm, but there is no such package
in the CentOS8 repository.
Would it be better to just remove the use of tz.UTC? I believe we
could use dateutil.tz.tzutc() instead.
Thanks,
Pierre Riteau (priteau)
[1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-train/Packages/p/
[2] Error trace below:
2020-07-22 16:33:11.207 26 ERROR wsme.api
[req-3c49884a-1412-42bb-a57e-e7c731360148
ef450a969a2945928d3ade785eaae860 19df0f36ede14c29be9ca476222f8ba9
default - -] Server-side error:
"module 'dateutil.tz' has no attribute 'UTC'". Detail:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/wsmeext/pecan.py", line 85,
in callfunction
result = f(self, *args, **kwargs)
File
"/usr/lib/python3.6/site-packages/cloudkitty/api/v1/controllers/storage.py",
line 71, in get_all
paginate=False)
File "/usr/lib/python3.6/site-packages/cloudkitty/storage/v2/influx.py",
line 311, in retrieve
begin, end = self._check_begin_end(begin, end)
File "/usr/lib/python3.6/site-packages/cloudkitty/storage/v2/influx.py",
line 271, in _check_begin_end
end = tzutils.get_next_month()
File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line
150, in get_next_month
return add_delta(start, datetime.timedelta(days=month_days))
File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line
104, in add_delta
return utc_to_local(local_to_utc(dt, naive=True) + delta)
File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line
52, in local_to_utc
output = dt.astimezone(tz.UTC)
AttributeError: module 'dateutil.tz' has no attribute 'UTC'
4:46 a.m.
Hi Pierre,
I submitted a patch to raise the minimum requirement for dateutil in
cloudkitty: https://review.opendev.org/#/c/742477/
However, how are those requirements taken into consideration when
packaging OpenStack in RDO? RDO packages for CentOS7 provide
python2-dateutil-2.8.0-1.el7.noarch.rpm, but there is no such package
in the CentOS8 repository.
RDO sticks to the version from base OS if a package is available
there, as long as it works with upstream projects.
In EL7 base python-dateutil 1.5 was too old so it is overridden by an
updated version in the RDO repo.
When we moved to EL8, python3-dateutil 2.6 included in the base OS was
new enough so it was no introduced in RDO for EL8.
The whole process of maintaing RDO deps is documented at
https://www.rdoproject.org/documentation/requirements/
Would it be better to just remove the use of tz.UTC? I believe we
could use dateutil.tz.tzutc() instead.
Yes backward compatibility would be good, if the upstream project is
happy with "available in RHEL8 base repo" justification.
Cheers,
Alan
3:39 a.m.
On Wed, 19 Aug 2020 at 11:46, Alan Pevec <apevec(a)redhat.com> wrote:
Hi Pierre,
> I submitted a patch to raise the minimum requirement for dateutil in
> cloudkitty: https://review.opendev.org/#/c/742477/
> However, how are those requirements taken into consideration when
> packaging OpenStack in RDO? RDO packages for CentOS7 provide
> python2-dateutil-2.8.0-1.el7.noarch.rpm, but there is no such package
> in the CentOS8 repository.
RDO sticks to the version from base OS if a package is available
there, as long as it works with upstream projects.
In EL7 base python-dateutil 1.5 was too old so it is overridden by an
updated version in the RDO repo.
When we moved to EL8, python3-dateutil 2.6 included in the base OS was
new enough so it was no introduced in RDO for EL8.
The whole process of maintaing RDO deps is documented at
https://www.rdoproject.org/documentation/requirements/
> Would it be better to just remove the use of tz.UTC? I believe we
> could use dateutil.tz.tzutc() instead.
Yes backward compatibility would be good, if the upstream project is
happy with "available in RHEL8 base repo" justification.
Cheers,
Alan
Hi Alan,
Thank you for your answer. We're changing code to be compatible with
older dateutil versions: https://review.opendev.org/#/c/747057/
However, did you notice that oslo.log also claims to require
python-dateutil>=2.7.0? [1]
It's not clear whether that's really needed: it used to require 2.5.3,
but that was bumped in [2] to synchronize with lower-constraints,
which itself must have been pulled from another dependency (but I
don't know which one).
[1] https://opendev.org/openstack/oslo.log/src/branch/master/requirements.txt...
[2]
https://opendev.org/openstack/oslo.log/commit/d0cd199ce88e40c427c09f553a5...
7:45 a.m.
Hi Pierre,
> > I submitted a patch to raise the minimum requirement for
dateutil in
> > cloudkitty: https://review.opendev.org/#/c/742477/
thanks for that!
> > However, how are those requirements taken into
consideration when
> > packaging OpenStack in RDO? RDO packages for CentOS7 provide
> > python2-dateutil-2.8.0-1.el7.noarch.rpm, but there is no such package
> > in the CentOS8 repository.
yes, Yatin and I had a chat the other day [1]
conclusion was "we got lucky until cloudkitty" :)
Cheers,
Alan
[1]
http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2020-08-19.log.html#...
7:48 a.m.
err, wrong quote! Below was reply to this part of your email:
However, did you notice that oslo.log also claims to require
python-dateutil>=2.7.0
yes, Yatin and I had a chat the other day [1]
conclusion was "we got lucky until cloudkitty" :)
[1]
http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2020-08-19.log.html#...
7:58 a.m.
On Fri, 21 Aug 2020 at 14:48, Alan Pevec <apevec(a)redhat.com> wrote:
err, wrong quote! Below was reply to this part of your email:
> However, did you notice that oslo.log also claims to require
> python-dateutil>=2.7.0
yes, Yatin and I had a chat the other day [1]
conclusion was "we got lucky until cloudkitty" :)
[1]
http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2020-08-19.log.html#...
Thanks, I suppose we would have seen issues if oslo.log was really
requiring a newer version of dateutil.
1363
days inactive
1365
days old
5 comments
2 participants
participants (2)
-
Alan Pevec -
Pierre Riteau