cci-moc / esi-leap Goto Github PK

The Containerfile explicitly installs mysql-connector and pymysql. Are these requirements for esi-leap? Should they be listed in requirements.txt?

If you create an offer with either of those blank, you'll get:

2019-08-05 23:28:17.116 19426 ERROR esi-leap   File "/home/centos/esi-leap/esi_leap/objects/offer.py", line 87, in create
2019-08-05 23:28:17.116 19426 ERROR esi-leap     return o.send_to_flocx_market()
2019-08-05 23:28:17.116 19426 ERROR esi-leap   File "/home/centos/esi-leap/esi_leap/objects/offer.py", line 72, in send_to_flocx_market
2019-08-05 23:28:17.116 19426 ERROR esi-leap     marketplace_offer_dict = self.to_marketplace_dict()
2019-08-05 23:28:17.116 19426 ERROR esi-leap   File "/home/centos/esi-leap/esi_leap/objects/offer.py", line 121, in to_marketplace_dict
2019-08-05 23:28:17.116 19426 ERROR esi-leap     offer_dict['end_time'] = offer_dict.pop('end_date').isoformat()
2019-08-05 23:28:17.116 19426 ERROR esi-leap AttributeError: 'NoneType' object has no attribute 'isoformat'

Notify users (projects?) when their lease is about to go away so they don't panic.

When creating a contract with an end-time, with or without a start-time, if the end-time is set to be earlier than current time (or start-time), the contract still gets created but raises errors in esi-leap-manager. And this contract cannot get deleted by cli.

As written, the Containerfile will always install the latest PyPi release. That means that even if the local Python sources are updated, someone building a container image will get the release version rather than their local changes, which may be surprising.

Is this intentional? Should we update the Containerfile to install esi-leap from the local sources rather than using the release version?

If any of the periodic jobs throws an exception or error, it will die silently. This means leases will not start or end.

When storing a value of 9999-12-31 23:59:59.999999 (the max datetime value in the SQL spec) in a database field, an overflow error will be thrown if the database backend is MySQL. Notably, this is the default value of a lease/offer/owner change's end time when an end time is not specified. This is due to MySQL storing 0 digits of precision for fractional seconds for datetime values by default and handling this by rounding up (which causes the overflow). This precision width must be set to 6 when initializing the schema (or if already initialized, must be fixed manually). This also means that versions of MySQL lower than 5.6 will not work with esi-leap (see https://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html).

Encountered while running functional tests-- two tests were failing consistently and both involved "offer list." The OpenStack client was returning an odd error along the lines of:

FileNotFoundError: [Errno 2] No such file or directory: '/tmp/nodes/<some_uuid>'

The UUID in the error message was consistent every time, which didn't make sense considering the tests create dummy nodes with new random names each time. I got the same error running openstack esi offer list on the command line, even though other OpenStack commands worked fine. Turns out there was an offer created on a dummy node with the UUID '<some_uuid>' and its corresponding file in /tmp/nodes didn't exist. Since esi-leap apparently tries to read/locate these dummy node files when returning active offers/leases, it fails here in a place it shouldn't, with an unhelpful error message.

It can be fixed, either by putting some valid JSON in the file esi-leap is looking for or by manually updating/deleting the offer/lease in the db, but this should still be fixed in esi-leap itself.