Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-05
14:36:54 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100
14:36:54 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387
14:36:56 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082
14:36:59 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941
14:37:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520
14:37:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021
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

Earlier   Later