Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-05
15:29:22 scottda mriedem: I'd have to think on that one. But I do recall we had issues....
15:29:23 smcginnis It was the whole discussion that nova is not an orchestration layer, it's just another component of the cloud, so why should it coordinate all actions. IIRC.
15:30:18 voelzmo @mriedem Not sure if deleting a thing and therefore also deleting things associated with it is already orchestration. But that might be nitpicking on the definition of words.
15:31:12 voelzmo The case I'm making is: I have to use pre-created ports to know their mac addresses up front, although I don't care about ports as separate entities once the VM is gone
15:31:16 scottda It might be that it's bad to automatically delete a persistent volume when deleting the VM that boots from it....user might want more control. I'll have to dig back for details...
15:31:21 voelzmo same as with boot volumes, thus the analogy
15:31:47 smcginnis If "deleting a thing" where the thing is from somewhere else, that's orchestration.
15:31:50 voelzmo and I'm not arguing to take control away from the user, I'm adding a new case in which you can give up that control if you like
15:32:08 voelzmo all existing cases of "more control" still exist and remain even the default
15:32:42 voelzmo What's even worse: The thing we're arguing about used to work like I'm proposing until the "bugfix" in Kilo
15:32:52 mriedem scottda: yes that's my assumption on the original use case for delete_on_termination with volumes - nova creates the volume, but you want it leftover after the server is deleted
15:33:15 mriedem voelzmo: well before kilo we had the other bug that nova would delete pre-created neutron ports when the server was deleted
15:33:20 mriedem which was also a nasty bug that pissed everyone off
15:33:24 voelzmo I can also create the volume upfront and provide it to boot_from_volume
15:33:33 voelzmo and still have nova delete it on VM deletion
15:33:48 voelzmo @mriedem that's the bug I'm talking about :)
15:33:53 mriedem voelzmo: i know
15:36:55 mriedem voelzmo: to be clear, i'm not totally against the idea, i'm just hesitant to add more stuff like this into nova
15:37:09 mriedem anyway, we're not close to pike specs anyway yet, so it'll simmer for awhile
15:37:29 mriedem either way, welcome :)
15:37:33 voelzmo @mriedem understood, thanks for the comments. I thought it will most likely not make it into ocata, so I just submitted it directly to pike
15:37:56 sahid sfinucan: mriedem ok no problem will update the code based on your comments
15:37:59 sahid thanks for the reviews
15:41:28 macsz mriedem: there was no meaningful response from the operators on https://review.openstack.org/#/c/397800/ (ML: http://lists.openstack.org/pipermail/openstack-operators/2016-November/012087.html ). do you think we can go forward and remove -2? I will address comments from PS2 today
15:42:54 mriedem macsz: can you follow up with johnthetubaguy or mikal to make sure rax isn't using that hook mechanism before we yank it?
15:44:10 mriedem macsz: i'll also fish in the operators channel one last time today
15:44:23 mordred mriedem: morning sir! in http://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail the example response shows a bunch of fields starting with total - but they are not in the documented set of responses
15:44:24 macsz mriedem: sir, yes, sir!
15:44:28 mordred mriedem: any idea which is correct?
15:45:03 mriedem http://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#id215 ?
15:45:29 mriedem mordred: let me dig
15:45:32 wznoinsk mriedem, yes, trivial, we're working on a permanent fix while workarounded and recheck in-flight (via zuul cli rather than gerrit)
15:45:41 mordred mriedem: thanks!
15:45:42 mriedem wznoinsk: thanks
15:46:30 mriedem sdague: reminder ping on https://review.openstack.org/#/c/415511/
15:46:42 openstackgerrit Rafael Folco proposed openstack/nova: DELETE all inventory for a resource provider https://review.openstack.org/416669
15:48:43 sdague mordred: I think the total* fields are real, just not documented
15:48:59 mordred sdague: awesome. should I file a bug?
15:49:07 sdague mordred: sure
15:49:12 mordred \o/
15:49:32 mriedem mordred: os-used-limits
15:49:36 mriedem that's the thing that provides those
15:49:58 mriedem https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/used_limits.py#L42
15:50:25 mriedem if i'm reading that gorp correctly, os-used-limits extends the limits API
15:50:52 mordred gotcha. so it used to be an extensoin - is now likely a part of the limits api due to miroversions yeah?
15:50:57 mriedem and adds the used limits (totals) to the response object from the limits controller
15:51:08 sdague mordred: yeh
15:51:19 mriedem mordred: well it's still an extension, but :)
15:51:20 mordred also - should I expect that the floatingips and security group fields will go away with proxy removal?
15:51:22 sdague mriedem: so, for good form on https://review.openstack.org/#/c/415511
15:51:24 mordred mriedem: :)
15:51:41 sdague mordred: yes, the code drops those at 2.36
15:51:45 mordred oh. duh. yah - I see that now
15:51:46 mriedem floatingip and security groups will work with microversion < 2.36
15:51:47 mordred awesome
15:52:10 mriedem after we drop nova-net, those won't work for nova-net backed systems at any microversion
15:52:19 mriedem because the code will literally be gone
15:52:46 sdague mriedem: on https://review.openstack.org/#/c/415511 ... could you put the body snippets of what the resources end up looking like? Mostly just because REST changes are much easier to historically review in specs when it shows actual sample response
15:52:57 mriedem mordred: anyway, yeah a bug for not having os-used-limits documented in the api-ref would be good
15:53:10 mriedem sdague: sure
15:53:17 sdague mriedem: the spec works for me otherwise
15:53:29 openstack Launchpad bug 1654316 in OpenStack Compute (nova) "total* fields in limits example response undocumented" [Undecided,New]
15:53:29 mordred mriedem: https://bugs.launchpad.net/nova/+bug/1654316
15:54:16 mordred sdague, mriedem: while I'm bothering you - do you happen to know off the top of your head if glance/neutron have equiv limits api calls?
15:54:29 openstackgerrit Matthew Booth proposed openstack/nova: libvirt: Add create_from_image and create_from_func to Backend https://review.openstack.org/333244
15:54:49 mriedem i know they have quotas...
15:54:59 mordred yah - quotas was the only thing I found
15:55:10 mordred is there a conceptual differences between quotas and limits?
15:56:35 mriedem i don't think so...
15:56:42 mriedem the limits API gets it's values from the quotas engine
15:57:03 mriedem the only difference is that os-used-limits extension which shows how much of a given quota you're using
15:57:39 mriedem which i realize it's totally awesome that we have like 6 different APIs related to quotas,
15:57:46 mriedem probably half of which don't actually do anything, like quota classes
15:58:17 mriedem which is why i want to kill the quota classes api but jay won't let me :P
15:58:19 openstackgerrit Diana Clarke proposed openstack/nova: api-ref: use the examples with paging links https://review.openstack.org/416312
15:58:21 mordred \o/
15:58:41 mordred it's also neat that some of these are very much admin functions
15:58:51 mordred like - for neutron:
15:58:53 mordred r=c.get('/v2.0/quotas')
15:58:56 mordred keystoneauth1.exceptions.http.Forbidden: Forbidden (HTTP 403) (Request-ID: req-17d9d1a0-cf68-4e96-bbb0-362bb2f9be2e)
15:59:14 mordred you know - a user could certainly never want to know what their quota is :)
15:59:38 mriedem mordred: for neutron, there is no limits api
15:59:58 mordred yah. only quotas
16:00:07 mriedem mordred: when creating a server(s), nova gets the port quota (hard limit) and then lists ports for the project, and then does the math inside nova
16:00:09 mordred the nova limits api totally works for end user - so thank you
16:00:20 mordred mriedem: wow. that's awesome
16:00:24 mriedem mordred: yup
16:00:47 mordred mriedem: I'm so glad I came back from vacation
16:00:54 mriedem mordred: hey, at least we only ask for the port id in the response now rather than the full port body response for all of them like we used to :)
16:01:04 mriedem just to do len(ports)
16:03:18 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance-exists notification https://review.openstack.org/403660
16:04:24 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance.rebuild.error notification https://review.openstack.org/396621
16:08:53 johnthetubaguy mriedem: FWIW, we don't use that plugin system that macsz is looking to remove
16:09:30 johnthetubaguy mriedem: my only slight reservation is folks that use the glance file backend attached to shared storage that is also attached to all their hypervisors, no idea if anyone has ever made that work though
16:10:10 jlvillal mriedem: Just wanted to remind you to talk to jaypipes, if you haven't already on that issue from last night.
16:11:03 openstackgerrit Stephen Finucane proposed openstack/nova: console: introduce basic framework for security proxying https://review.openstack.org/345396
16:11:04 openstackgerrit Stephen Finucane proposed openstack/nova: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398
16:11:04 openstackgerrit Stephen Finucane proposed openstack/nova: console: introduce framework for RFB authentication https://review.openstack.org/345397
16:11:05 openstackgerrit Stephen Finucane proposed openstack/nova: console: provide an RFB security proxy implementation https://review.openstack.org/345399
16:14:48 dmsimard o/ I noticed that there's an entry point for wsgi_scripts with the placement api: https://github.com/openstack/nova/blob/3d45ab20457abff81be03db7a1c3780b713afde6/setup.cfg#L72-L73

Earlier   Later