| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 18:29:54 | efried | jaypipes Roger that. If it helps, the words I wrote down while we were chatting were: "scheduler client report" | |
| 18:44:32 | mordred | mriedem: in my ongoing effort to report 'fun' api interactions ... | |
| 18:44:43 | mordred | efried: (I just opened that link, will look in a sec) | |
| 18:45:03 | cfriesen | weird question....if we start with nova version N, and upgrade everything to N+1, am I correct that Service._check_minimum_version() would prevent us from downgrading even if the RPC is explicitly still set to something suitable for version N? | |
| 18:45:34 | jaypipes | efried: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py | |
| 18:45:54 | mordred | mriedem: today I learned that GET /os-simple-tenant-usage?start=%s&end=%s&detailed=%s ... which takes an ISO 8601 date string as input for start and ed | |
| 18:46:11 | mordred | mriedem: fails if your ISO 8601 date string includes a timezone offset | |
| 18:46:23 | jaypipes | efried: and an example of usage from the scheduler: https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L170 | |
| 18:46:59 | mriedem | mordred: yeah https://developer.openstack.org/api-ref/compute/?expanded=list-tenant-usage-statistics-for-all-tenants-detail#id365 | |
| 18:47:10 | mordred | mriedem: so it is incumbent on a consumer to take their ISO 8601 date string, apply the timezone offset expressed in the string and then submit the string without the timezone offset | |
| 18:47:24 | jaypipes | efried: and where the compute resource tracker calls it: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L759-L763 | |
| 18:47:39 | mordred | mriedem: indeed - so it is documented, which is nice :) | |
| 18:48:45 | mordred | mriedem: however, also, python-novaclient does this: | |
| 18:48:48 | mordred | return self._list( | |
| 18:48:49 | mordred | "/os-simple-tenant-usage?start=%s&end=%s&detailed=%s" % | |
| 18:48:51 | mordred | (start.isoformat(), end.isoformat(), int(bool(detailed))), | |
| 18:48:54 | mordred | "tenant_usages") | |
| 18:49:17 | mordred | so if the datetime passed to python-novaclient is a datetime that has a tzinfo attached, sadness occurs - because it isn't actually isoformat that is accepted | |
| 18:49:44 | mordred | (this is what results from starting by looking at the novaclient code instead of the docs for how to work an API, btw) | |
| 18:50:57 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 18:51:02 | dansmith | mriedem: rebased ^ | |
| 18:51:11 | mriedem | mordred: it also does this thing https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/usage.py#L32 | |
| 18:51:53 | mriedem | which is related to this thing in the api https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/simple_tenant_usage.py#L228 | |
| 18:52:35 | mordred | fascinating | |
| 18:53:26 | mordred | mriedem: I'm truly curious as to the reasoning behind defining our own format that isn't the ISO standard but close to it - but it's not super important ... I mostly just learned a new thing today and want to check in and see if it was bug or feature | |
| 18:53:53 | mriedem | changing it would be a microversion | |
| 18:54:04 | mriedem | why it's that way, you'd have to ask vish or someone | |
| 18:54:44 | sdague | or mordred or jaypipes | |
| 18:54:47 | mordred | I don't think it needs to change -since it's clearly documented and has obviously been implemented on purpose -- I've got the conversion call written on my side now | |
| 18:54:54 | mriedem | yeah no sh*t, *those* guys | |
| 18:55:01 | mordred | jaypipes: oh - you're here ... can you tl;dr me? ^^ | |
| 18:55:35 | jaypipes | mordred: ya, me here. | |
| 18:55:37 | mordred | mriedem: would I be safe in assuming that anywhere nova takes a date it's gonna be in that format and not full ISO? | |
| 18:55:56 | mriedem | i don't know where else we take a date | |
| 18:56:51 | mriedem | the compute api ref has a standard description for fields in the response that are a datetime | |
| 18:57:41 | mriedem | e.g. https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L1648 | |
| 18:57:58 | jaypipes | sdague: I have no part in the making of os-simple-tenant-usage... | |
| 18:58:58 | sdague | mordred: the best recollections I've got are there are at least 3 different time formats because people picked things oddly (all predates me) | |
| 18:59:20 | sdague | I think the oslo utils actually take any of them and digest into the same thing | |
| 18:59:39 | sdague | that was an early markmc push from when I first showed up | |
| 19:02:52 | mordred | edleafe: ah - that probably makes sense | |
| 19:03:07 | mordred | sdague: nod. hrm - I should ping markmc and ask him what he remembers | |
| 19:03:41 | mordred | I mostly found it weird since we ALSO use the iso8601 library in OpenStack ... so doing work to support a subset of ISO 8601 just seems weird | |
| 19:04:32 | sdague | when did iso8601 get added? | |
| 19:04:41 | sdague | you have to realize, a lot of this code is 2012 era stuff | |
| 19:08:41 | sdague | mordred: simple tenant usage is 7726b3d763a136347f2324e630f0a3cdc60a045b (Aug 2011) | |
| 19:08:59 | sdague | iso8601 is 7726b3d763a136347f2324e630f0a3cdc60a045b (Mar 2011) | |
| 19:09:20 | sdague | it just looks like simple tenant usage was written to python date format and straight to db | |
| 19:09:53 | mordred | sdague: man - 2011 was a long time ago | |
| 19:09:57 | sdague | yep | |
| 19:10:00 | sdague | git log -S for the win | |
| 19:10:04 | mordred | ++ | |
| 19:10:45 | mriedem | efried: did you see that nova-specs docs on longer build? | |
| 19:10:56 | mriedem | /home/user/git/nova-specs/doc/source/specs/juno/implemented/pci-passthrough-sriov.rst:412:Citation [VIF_DETA] is not referenced. | |
| 19:11:01 | mordred | sdague: fwiw - today I added a default value to shade for "start" of 2010-07-06 - since it's impossible for an openstack cloud to have usage going back before that :) | |
| 19:12:41 | mriedem | *no longer | |
| 19:13:35 | efried | mriedem "nova-specs docs on longer build"? | |
| 19:13:51 | efried | oh... | |
| 19:13:53 | mriedem | http://logs.openstack.org/81/461481/3/gate/gate-nova-specs-docs-ubuntu-xenial/9e65575/console.html#_2017-05-23_18_19_21_056047 | |
| 19:13:55 | mriedem | and local | |
| 19:14:06 | mriedem | started in the last 24 hours | |
| 19:15:08 | mriedem | the citations in that file all look ok to me | |
| 19:15:22 | efried | jaypipes Thanks, will peruse. | |
| 19:15:42 | efried | mriedem Sorry, what does "nova-specs docs no longer build" mean? | |
| 19:15:49 | jaypipes | efried: peruse. persue. do with it what you may :) | |
| 19:16:02 | mriedem | efried: you asked jaypipes to review your nova-specs patch, right? | |
| 19:16:04 | mriedem | he approved it, | |
| 19:16:06 | mriedem | it failed in the gate, | |
| 19:16:13 | mriedem | meaning the docs job for nova-specs is broken | |
| 19:16:22 | sdague | mordred: nice | |
| 19:16:23 | efried | mriedem Oh. | |
| 19:16:25 | mriedem | looking at logstash, something changed in the last 24 hours | |
| 19:16:30 | mriedem | my guess is some upstream library | |
| 19:16:38 | efried | Not by design | |
| 19:16:43 | efried | or because I'm a bad, bad person. | |
| 19:16:49 | mriedem | i recreated locally | |
| 19:16:57 | mriedem | i'm checking to see which packages changed in the last 24 hours | |
| 19:17:14 | mriedem | but it's nearly nap:30 here and i'm having a hard time caring | |
| 19:23:56 | mriedem | i don't see any recent package releases that look related | |
| 19:26:34 | mriedem | efried: it's sphinx 1.6.1 | |
| 19:27:03 | efried | mriedem Cool, guess nova-specs doesn't get auto-updates to requirements from g-r. | |
| 19:27:12 | mriedem | nova-specs doesn't use upper-constraints | |
| 19:27:14 | efried | mriedem Shall I propose that? | |
| 19:27:23 | mriedem | no | |
| 19:27:33 | efried | (the !1.6.1, that is, not adding the bot) | |
| 19:27:35 | mriedem | well, it's on purpose for some reason | |
| 19:28:11 | mriedem | i've go the thing local | |
| 19:28:13 | mriedem | just writing the bug | |
| 19:29:06 | cdent | edleafe: quick! rewrite placement to use etcd while I feed jaypipes crunchie bars | |
| 19:29:08 | mriedem | i don't really know why we don't use upper-constraints for building nova-specs docs really | |
| 19:29:13 | jaypipes | melwitt: tell James I'm going to hire a choir of angels to sing to him. :) | |
| 19:30:09 | sdague | mriedem: it just never got there | |
| 19:30:38 | sdague | the assumption I think is it was just fast enough to locally fix | |
| 19:30:39 | melwitt | jaypipes: lol :) | |
| 19:30:53 | mriedem | sdague: i don't even know that the docs jobs would use it anyway | |
| 19:30:57 | mriedem | since they don't do tox -e docs | |
| 19:31:03 | mriedem | i think they do build_sphinx directly right? | |
| 19:31:06 | jaypipes | cdent: nom nom! | |
| 19:31:07 | sdague | mriedem: yeh, good point, I don't know | |
| 19:35:08 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Blacklist sphinx 1.6.1 https://review.openstack.org/467367 | |