| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-05 | |||
| 14:37:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 14:37:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520 | |
| 14:37:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Add method to invalidate metadata cache https://review.openstack.org/453673 | |
| 14:52:53 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Spec to add per instance timeout for LM https://review.openstack.org/442809 | |
| 15:00:55 | jaypipes | cdent: it's not about "doing a bit of math on the client side". rather, it's just making the REST API more useful, IMHO. | |
| 15:02:12 | cdent | I get where you're coming from, but you solution adds an endpoint for a specific result that can be serviced by something more generic that fits in with the existing grammar | |
| 15:02:37 | cdent | And I'm trying to toe the line on "only add stuff if we have to" | |
| 15:02:45 | cdent | and in this case there are plenty of ways to "not have to" | |
| 15:03:05 | cdent | If we decide to go with /usages, that's fine it's not a big deal | |
| 15:03:10 | edleafe | And is "usage" a resource? (in the REST sense of the word) | |
| 15:03:13 | cdent | but since we can do it another way, that's fine too | |
| 15:03:48 | jaypipes | edleafe: we already have /r-p/{uuid}/usages | |
| 15:05:20 | jaypipes | cdent: in either, case I'm fine doing it only in /allocations to start off and adding the /usages at a later time. | |
| 15:05:22 | jaypipes | mriedem: ^ | |
| 15:06:08 | cdent | jaypipes: that seems like a reasonable path: if it turns out it is just too damn slow or code-messy to do the math client side, then adding later is great | |
| 15:06:22 | jaypipes | yep, ok with me. | |
| 15:06:33 | jaypipes | for some reason I thought we had a top-level /usages endpoint already :( | |
| 15:07:12 | cdent | jaypipes: yeah, I had to check to confirm it. I keep going back to the DECLARATIONS var in handler.py over and over. Makes me very glad it is there. | |
| 15:07:35 | edleafe | So would usages be a summary of allocations by resource class? | |
| 15:07:49 | jaypipes | correct. | |
| 15:08:01 | jaypipes | as in "a usage report". | |
| 15:08:15 | edleafe | ok, that's what I thought | |
| 15:09:14 | mriedem | ala https://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#show-rate-and-absolute-limits | |
| 15:09:22 | mriedem | "maxTotalCores": 20, | |
| 15:09:26 | mriedem | "totalCoresUsed": 0, | |
| 15:09:33 | mriedem | yay quotas in placement | |
| 15:10:08 | melwitt | each compute node is a RP, right? so with the /allocations query, there would be maybe hundreds of entries to add together for every quota check | |
| 15:11:08 | cdent | one sec but it may be that we have to do it jay's way | |
| 15:12:05 | cdent | nope, never mind | |
| 15:12:15 | jaypipes | melwitt: correct. | |
| 15:12:21 | cdent | I was worried that if a user had multiple instances on the same rp the output would be weird | |
| 15:12:26 | cdent | but yeah, could be hundreds | |
| 15:12:49 | jaypipes | melwitt: it's not that it cannot be done, just that it could be done more simply by the placement API. but I'm cool doing that in a followup patch. | |
| 15:13:10 | melwitt | yeah, just thinking about it more | |
| 15:14:09 | mriedem | how would it be hundreds when the default max limit on instances is 20? | |
| 15:14:19 | melwitt | hundreds of compute nodes | |
| 15:14:21 | melwitt | is common | |
| 15:14:34 | mriedem | yeah but aren't you asking for allocations for a given project? | |
| 15:14:36 | melwitt | and allocations are per resource provider | |
| 15:14:50 | cdent | mriedem: you make an excellent point | |
| 15:15:02 | mriedem | but my project by default can only allocate up to 20 instances right? | |
| 15:15:13 | mriedem | b/c allocations.consumer_id == instance.uuid | |
| 15:15:17 | melwitt | oh, hm | |
| 15:15:52 | jaypipes | there will still be 3x that number of records in the normal case (a record per instance for VCPU, MEMORY_MB, and DISK_GB of course) | |
| 15:16:28 | jaypipes | but anyway, like I said, it's nothing more than an ease-of-use thing (doing the top-level /usages endpoint) for me. | |
| 15:16:59 | mriedem | my point is i don't like 2 ways to skin the cat | |
| 15:17:15 | jaypipes | mriedem: one is a summary view, the other is a details view, that's all this is. | |
| 15:17:16 | mriedem | if /usages is the thing that's better and keeps the math on the server side, then that seems fine | |
| 15:17:31 | mriedem | i don't want to provide 2 apis when one is needed | |
| 15:17:38 | jaypipes | mriedem: we already have the /allocations endpoint, though. which is what cdent is saying. | |
| 15:17:39 | mriedem | so let's pick the one correct api | |
| 15:17:43 | melwitt | yeah, I was kinda thinking why not just do /usages only then | |
| 15:17:59 | mriedem | has anyone looked at the turd sandwich that is the compute api lately? :) | |
| 15:18:02 | mriedem | let's not do that again | |
| 15:18:27 | jaypipes | mriedem: Matt, nobody here is recommending making placement API into a turd sandwich. | |
| 15:18:34 | mriedem | jaypipes: so rather than change /allocations to take query params, we add /usages if that's better | |
| 15:18:45 | cdent | we do not have just /allocations yet, we have /allocations/{consumer_uuid}, burt limiting the numbers of paths seems nice | |
| 15:18:48 | jaypipes | mriedem: both the detail view (/allocations) and the summary view (/usages) are useful. | |
| 15:18:57 | jaypipes | cdent: good point. | |
| 15:19:04 | mriedem | jaypipes: they are not useful if we aren't using them both | |
| 15:19:09 | mriedem | one will be technical debt | |
| 15:19:34 | mriedem | so what is the one true best api that we can provide for melwitt's quota counting client side code? | |
| 15:19:36 | mriedem | and let's do that | |
| 15:19:55 | jaypipes | mriedem: my guess is that as soon as we add a summary view, someone will say "but what allocations are underneath that summary view?" | |
| 15:19:59 | jaypipes | mriedem: but meh. | |
| 15:20:10 | cdent | jaypipes: exactly my point | |
| 15:20:12 | mriedem | if someone has a valid use case later, then we add a new thing | |
| 15:20:23 | melwitt | I am still not clear on what the difference between a usage object and a allocation object is either | |
| 15:20:24 | cdent | people will want the details, and we have code that creates most of those details already | |
| 15:20:35 | jaypipes | mriedem: for the quota-counting use case, I believe GET /usages?project_id=X&user_id=Y is the best fit. | |
| 15:20:48 | mriedem | melwitt: idk either | |
| 15:20:54 | mriedem | because it wasn't modeled in the spec as it came up later | |
| 15:21:04 | mriedem | jaypipes: did you think /usages already existed when you commented on that in the spec? | |
| 15:21:28 | jaypipes | melwitt: a usage object is an aggregate view (total number of VCPU used, instead of X number of allocation records each with a VCPU record) | |
| 15:21:37 | mriedem | oh i see /resource_providers/{uuid}/usages | |
| 15:21:51 | melwitt | I'm not seeing any example of one in a response in the gabbits | |
| 15:22:30 | mriedem | melwitt: it's in the allocations gabbits | |
| 15:22:31 | mriedem | for /resource_providers/{uuid}/usages | |
| 15:22:40 | melwitt | ah, thanks | |
| 15:23:23 | mriedem | and usage.yaml | |
| 15:24:41 | melwitt | in usage.yaml all the responses are empty, I think. I was just looking to get an idea what the existing usages response looks like | |
| 15:25:04 | melwitt | but it's been explained, aggregate view, and that would be ideal for the quota checks | |
| 15:26:48 | mriedem | {'resource_provider_generation': 1, 'usages': {'VCPU': 2, 'MEMORY_MB': 2048, 'DISK_GB': 80}} | |
| 15:26:52 | mriedem | something like that i think | |
| 15:27:40 | melwitt | gotcha, thanks | |
| 15:27:43 | cdent | mriedem, melwitt line 353 in this https://review.openstack.org/#/c/370204/2/nova/tests/functional/api/openstack/placement/gabbits/fullrep.yaml | |
| 15:27:59 | cdent | and 441 | |
| 15:28:58 | melwitt | perfect, thanks | |
| 15:37:03 | dansmith | successful devstack multi-cell run: https://review.openstack.org/#/c/436094 | |
| 15:58:20 | openstackgerrit | Huan Xie proposed openstack/nova master: WIP: use os-xenapi V2 https://review.openstack.org/453493 | |
| 16:03:03 | sfinucan | mriedem: Quick question on https://review.openstack.org/#/c/433603/ | |
| 16:04:03 | sfinucan | I've the Sphinx integration for cliff done, but it'll be a while before it merges and a suitable version makes it's way into g-r | |
| 16:04:45 | sfinucan | I also need to drop a load of commands from nova-manage that are no longer necessary, but I figure we need a cycle of deprecation before doing so | |
| 16:05:23 | sfinucan | How do I track that from a spec/bp perspective? specless bp for this cycle (to deprecate commands) and a specful one for Queens to do the rewrite? | |
| 16:06:44 | mriedem | sfinucan: we don't need a bp to deprecate commands | |
| 16:07:16 | sfinucan | No? Sweet. I'll re-target that for Queens so | |
| 16:09:32 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: A spec for idempotent custom resource classe creation https://review.openstack.org/453732 | |
| 16:09:38 | cdent | mriedem, jaypipes, edleafe ^ | |
| 16:09:49 | cdent | feh, typo right at the start mehness | |
| 16:09:58 | jaypipes | cdent: cool, thanks! | |