| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 17:42:27 | jaypipes | cfriesen: sure, no disagreement. | |
| 18:00:40 | ildikov | lyarwood: sfinucan: hi | |
| 18:00:46 | ildikov | lyarwood: sfinucan: if you have some time there're two patches related to the new Cinder attach/detach flow with one +2 already: https://review.openstack.org/#/c/459111/ https://review.openstack.org/#/c/459113/ | |
| 18:00:55 | ildikov | lyarwood: sfinucan: tnx :) | |
| 18:06:48 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/467344 | |
| 18:10:26 | efried | jaypipes johnthetubaguy mordred Would y'all please have a look at this spec update? Been +2 for a few weeks. https://review.openstack.org/#/c/461481/ | |
| 18:12:02 | efried | But the pen IS mightier than the sword, so... | |
| 18:12:07 | jaypipes | :) | |
| 18:14:03 | jaypipes | efried: done. | |
| 18:14:10 | efried | jaypipes Thanks dude. | |
| 18:16:42 | efried | jaypipes Still on my list to ask you for that pointer to the shared resource pool code. Is that a quick answer? | |
| 18:17:17 | jaypipes | efried: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/shared-resources-pike | |
| 18:20:58 | efried | jaypipes Okay, looking through. I know you've slept (in multiple time zones) since then, so to refresh your memory on the conversation: I'm looking to get my compute driver itself to do the registration of its shared storage pool. | |
| 18:21:21 | jaypipes | efried: ah. yeah, sorry.. one sec | |
| 18:21:45 | jaypipes | efried: https://review.openstack.org/#/c/457782/ | |
| 18:21:49 | efried | jaypipes As impressive as your SQL construction is... ;-) | |
| 18:21:54 | jaypipes | efried: that's more what you're looking for I think? | |
| 18:21:58 | efried | ... | |
| 18:22:20 | jaypipes | speaking of which... dansmith, if you or bauzas have a chance to review https://review.openstack.org/#/c/457782/, that would be great | |
| 18:22:44 | efried | hmph, I've been watching this change set; but clearly didn't realize what I was looking at... | |
| 18:22:48 | dansmith | oh that fell off, I'll look | |
| 18:28:14 | efried | jaypipes I don't think this is quite what I'm looking for. I do think I'd like to do it from get_inventory(); but what I'm looking to do involves talking to the placement API and saying something like, "Do ya got a shared storage pool with UUID <uuid>? No: Okay, here it is. ==> And this compute host is part of it." | |
| 18:29:00 | jaypipes | efried: yeah, you'll have to wait a bit for a few more patches in that shared-resources-pike series to get to that | |
| 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 | |